Refactor client API context to remove per-component optional handling

[Pradeep-kumar1202]

Summary

Refactors AllApiDataContextNew so components consuming payment data no longer need to repeatedly handle clientData and sdkConfigData as optional values.

What changed

• Replaced the context tuple:

  (option<clientResponse>, option<sessions>, option<sdkConfig>)

  with a single optional context record containing:

  • Required clientData
  • Required sdkConfigData
  • Optional sessionTokenData

• Updated NavigationRouter to create the context value only after both the /client response and SDK configuration are available.

• Split ParentPaymentSheet into:

  • A loading boundary that handles unavailable API data.
  • Data-dependent sheet content that consumes concrete values.

• Added two context access patterns:

  • useData for components rendered after required data is available.
  • useOptionalData for top-level components that must also render during loading.

• Updated payment methods, saved payment methods, dynamic fields, hosted checkout, confirm button, redirect flow, and express checkout consumers to use the new context structure.

• Removed repeated Option.map, Option.flatMap, and Option.getOr operations for fields such as:

  • Payment type
  • Guest-customer status
  • Merchant name
  • Return URL
  • SDK next action
  • Customer payment methods

• Kept session-token data optional because its failure is non-blocking.

Why

The /client response and SDK configuration are required before the payment UI can be constructed correctly. Previously, every consumer independently handled their absence and supplied fallback values.

This resulted in duplicated optional handling and allowed components to temporarily consume fallback values while the required APIs were still loading.

The new structure handles API-data availability at the rendering boundary and lets dependent components consume the actual response values directly.

Behaviour

• The payment-sheet loader remains visible until both client data and SDK configuration are available.
• Components below the loading boundary receive concrete API data.
• Components that render during loading continue to use optional access.
• Session-token handling remains optional and non-blocking.
• No API contracts, request construction, or response parsing have been changed.

Validation

• npm run re:check
• git diff --cached --check