Composable checkout — follow-ups (tracking)

[field123]

Follow-ups from #368 (merged) that aren't covered by existing PRD slices.

Already tracked elsewhere — not duplicated here: account checkout → #322 · 3DS/requires_action → #324 · legacy pipeline rip-out → #326.

Genuinely-new (no existing slice):

• HIGH — payment integrity: harden free-vs-paid when cart meta.display_price is unavailable. pay.ts falls back to summing parsed items and treats 0 as free, so a paid cart could settle free with no charge if items don't parse (latent — the cart-hash 409 guards it today). Fix must not break legitimately-free orders that lack meta.
• verify confirmOrder paymentID + stop swallowing its failure (charged order could be left unreconciled).
• order custom fields (EP Flows, net-new in feat(ep-commerce): composable single-page checkout + EP-native Stripe + order custom fields #368): allow-list / namespace shopper-supplied keys so a client can't overwrite defined slugs (e.g. consent flags).
• confirmation page: real download links for digital products (order-items / file-href fetch).
• EPStripePayment: optionally suppress the PaymentElement's default Country+Postal (granular billingDetails).
• reusable EPCheckoutError / EPOrderConfirmation primitives (so consumers don't hand-wire success/error surfacing).
• better-auth migration (retire the cookie/session bridge).

Context: #368 delivered the guest Stripe happy path (≈ slices #320/#321, now closed) with ISO divergences — single-page EPCheckoutFormProvider form layer (vs refAction-driven existing components), card-only EPStripePayment, shipping optional — plus net-new order custom fields (Flows), a zero-total/free path, and a confirmation redirect. The form-layer divergence is worth a conscious reconciliation with the PRD owner (#317).

[field123]

Two refinements from a checkout design review

1. Reframe "suppress the PaymentElement's default Country + Postal".

This follow-up should not be taken at face value. Country + Postal are the minimal AVS set Stripe deliberately keeps when billing collection is reduced — they feed Address Verification, which issuers use in decline decisions. Suppressing them blindly risks lowering authorization rates. They are only safe to suppress if postal + country travel via the ConfirmationToken (i.e. billingDetails:'never' plus passing the omitted fields at confirm time, per Stripe's "Control billing details collection"). Recommend folding this into the collectBilling: "form" | "stripe" | "auto" design proposed on #317 (the "form" path already passes billing via buildBillingDetails(session)), with a guard that falls back to "auto" when billing isn't derivable — rather than an unconditional suppression.

2. Add: server-authoritative shipping requirement (sibling of the free-vs-paid HIGH item).

requiresShipping is currently a client-supplied flag, and when false the body builder silently ships to the billing address. A client can therefore set requiresShipping:false on a cart containing a physical item and have it ship to billing with no error — a fulfillment/integrity gap of the same shape as the free-vs-paid one. Hardening: infer "shipping required" from the cart's shippable item flags, server-side, and let the client flag only add requirement, never suppress it. Same "server is the sole authority" principle as the free-vs-paid fix; worth doing in the same pass.