Make the custom fields limit configurable (setting + filter)

[Pichinov-Jose]

Problem

CustomFields::MAX_FIELDS hard-caps the number of custom fields exposed per object type at 200. On sites that rely heavily on custom fields (ACF & similar), every field past the cap silently disappears from the schema — and any server-side mapping bound to those fields stops syncing, with no error and no way to raise the limit.

Real-world case: a production catalog with ~500 eligible fields lost 246 product fields (schema went from 499 to 253 exposed fields) after an update reset a locally raised limit.

Change

Default behaviour is unchanged (200). The limit becomes configurable:

• CustomFields::getLimit() reads the new Custom Fields Limit setting (option splash_custom_fields_limit), passes it through a splash_custom_fields_limit filter, and falls back to MAX_FIELDS;
• the custom fields parser (Post/CustomTrait) and the settings page descriptions use the effective limit;
• a number field is added to the Products section of the settings page (the admin API already supports it).

Sizing notes

Measured on the catalog above with the limit raised to 1200: the Product schema (499 fields) builds in under 400 ms for a ~300 KB serialized schema — comfortably within webservice limits. The default stays low on purpose; the setting simply lets a site opt in to what its own catalog needs.

🤖 Generated with Claude Code

[Pichinov-Jose]

Added a second commit (ffd114b): custom fields discovery is now scoped to the object's own post type. Core get_meta_keys() scans the whole postmeta table, so every object type was offered every meta of the site — order metas showed up as Product custom fields, and meta keys with invalid identifiers (e.g. legacy PayPal metas with spaces) triggered schema warnings on unrelated objects. product also includes its variations; objects without a known post type keep the legacy site-wide behaviour.