Enforce a payment provider's metadata limits.

Only items, answer_ids, modifiers and allocations can realistically exceed the per-value length limit — they grow with the number of listings/options/modifiers/package-picks selected (answer-triggered modifiers ride the modifiers refs). All other fields (name, email, address, etc.) are already constrained by form validation to lengths well below the smallest provider limit (255).

Square also caps the number of entries: a customisable-day checkout that fills its optional fields (date, day_count, answer_ids, …) plus a modifiers ref can reach the 10-entry limit, so when maxEntries is supplied the key count is checked too and surfaces the same batching error rather than a generic provider rejection.

thank_you_url is not handled here. It is the one provider-cap-sensitive field that must not fail the checkout (a long operator URL on a folded paid parent is purely a post-completion redirect), so an over-cap URL is dropped before the metadata is signed, in buildItemsMetadata. Capping it here — after signPrice — would strip a key the proof was signed with, so the webhook's verification would classify the paid session as tampered. Bounding it pre-sign keeps the signed payload and the emitted metadata identical.