feat(payment): Stripe OCS, make payment validation request non-blocking

[PavlenkoM]

What/Why?

After a successful client-side Stripe confirmation, the Stripe CS and OCS payment
strategies send a second submitPayment request so the backend can validate the
payment and finalize the order. This round trip can be slow, and the shopper is kept
waiting on a payment that Stripe has already confirmed.

This PR adds an optional asyncPaymentValidation flag to StripeInitializationData.
When enabled, both strategies send the second submitPayment request without awaiting
the response and resolve execute() immediately, letting checkout proceed to order
confirmation. Errors from that request are intentionally ignored (.catch(noop)): the
payment is already confirmed on the Stripe side, so the order status is reconciled by
Stripe webhooks even if the validation request fails or doesn't complete.

Only the success path is affected. Declined/failed Stripe confirmations behave exactly
as before: the error-status update request is still awaited and the error is thrown to
the shopper.

Rollout/Rollback

• The flag is computed and served by the backend via the payment method's
  initializationData, gated by the PROJECT-8987.ocs_async_payment_validation
  experiment. The backend sends asyncPaymentValidation: true only when the experiment
  is enabled for the store and the merchant has Stripe webhooks configured — since
  webhooks become the finalization path whenever the non-blocking request doesn't
  complete (e.g. interrupted by the redirect to order confirmation), stores without
  webhooks never receive the flag.
• With the experiment off (default), behavior is unchanged.
• Rollback is ramping down / disabling the experiment; no code revert required.

Testing

Stipe OCS + Checkout Session

Before:

Screen.Recording.2026-08-28.at.12.04.59.mov

After:

Screen.Recording.2026-08-28.at.12.13.39.mov

Stripe OCS + Payment Intent

Before:

Screen.Recording.2026-08-28.at.11.57.47.mov

After:

Screen.Recording.2026-08-28.at.12.01.36.mov

---

Note

Medium Risk
Changes post-confirmation payment finalization timing; when enabled, order completion may depend on webhooks if the background validation request fails.

Overview
Adds optional asyncPaymentValidation on StripeInitializationData so Stripe Checkout Session and OCS (Payment Intent) strategies can finish checkout without waiting on backend validation after Stripe confirms the payment.

When the flag is true and confirmation succeeds, both strategies still issue the second submitPayment, but they fire-and-forget it (submitPayment(...).catch(noop)) and execute() resolves immediately. Declines and other Stripe error paths are unchanged—they still await error-status updates and surface failures to the shopper.

When the flag is false or unset, behavior stays the same: the second submitPayment is awaited, and failures still trigger the existing “proceed” / error handling (including CS paid-session handling).

Unit tests cover flag-on (non-blocking, ignored second-request errors) vs flag-off (await and propagate errors) for CS and OCS.

^{Reviewed by Cursor Bugbot for commit 3bbac19. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Reviewed by Cursor Bugbot for commit 3bbac19. Configure here.}