feat(point-of-sale): add paymentvalidations intercept types

[aaronschubert0]

Why

Enables payment-type interception (cash first) for extensible client-side validations — e.g. compliance workflows blocking cash tenders until required data is collected. Types-only and @private.

What

Adds the second interceptable workflow to the POS surface's private intercept API: paymentvalidations, dispatched when staff selects a payment method on the payments screen.

Follows the pattern established in #4520:

• New POS_INTERCEPT_NAMES entry: PAYMENT_VALIDATIONS: 'paymentvalidations'
• New ShopifyInterceptMap entry so shopify.intercept() picks up the workflow through the map generic — no changes to globals.ts
• New payload types: PaymentValidationsEvent, InterceptedPaymentMethod, InterceptedPaymentMethodType

Also renames the first workflow per review, so both interceptable workflows follow one *validations naming scheme:

• beforecheckout → cartvalidations (POS_INTERCEPT_NAMES.CART_VALIDATIONS, BeforeCheckoutEvent → CartValidationsEvent)
• Safe pre-release: 2026-10-rc only, @private; the POS adapter consumes the constant symbolically (companion PR wiring bumps in lockstep)

InterceptResult / Operation / ValidationAdd are shared unchanged: ERROR blocks the selected method, WARNING does not.

Payload

• paymentMethod: {type, identifier?} — type is a stable string vocabulary (the internal numeric PaymentOptionType never crosses the boundary), constrained to 'cash' for v1; further method kinds join the union as they become interceptable. identifier is reserved for method types a shop can have several of (custom / local payment methods); unused for cash. Matching is exact on the pair.
• amount: MoneyV2 — the per-tender amount in presentment currency.

Intentionally minimal for v1:

• No split-payment context — interceptors see each split leg's amount independently; cross-leg aggregation (e.g. structuring detection) is future work.

References

• API contract: Shopify/ui-api-design#1557
• Decision issue: shop/issues-retail#31710
• Prior art: feat(point-of-sale): add POS intercept API types #4520
• Companion PRs: extensibility host bridge + POS adapter (to follow)

[vctrchu]

Add transactionId

[aaronschubert0]

Reversed after discussion — dropping transactionId from v1. The host cannot guarantee an id at selection time (Transaction.id?), so the field would be unreliable at exactly the moment it dispatches; payload stays paymentMethod + amount. Can revisit if a concrete correlation need lands.

[vctrchu]

/snapshot