Add platform attestation (Apple App Attest / Google Play Integrity) for mobile clients at flow initiation

[Malith-19]

Description

As part of the secured-by-default flow initiation model (parent: #2380), mobile clients calling POST /flow/execute to initiate a new flow must prove their app's binary identity. Cookies (used for browser SPAs) and App Secrets (used for backend clients, #3451) are not a good fit for standalone mobile apps. Instead, mobile clients present a platform attestation assertion on the first /flow/execute call — Apple App Attest on iOS and Google Play Integrity on Android — which Thunder verifies against the registered app identity before issuing the executionId and challengeToken.

This was agreed in the design discussion #2744 (Implementation Plan, step 3): "Mobile clients — Platform attestation (Apple App Attest / Google Play Integrity)." Note the discussion flags this as still in the research phase: further research is needed to confirm current mobile SDK support for the required redirections and server-side checks before the integration design is finalised.

This issue tracks both platforms because the verifier component, configuration model, and flow wiring are shared; only the per-platform assertion verification differs. If effort proves significant, the two platform tracks below can be split into separate issues.

Implementation Notes

Shared infrastructure

• Add an internal attestation verifier component that validates a platform assertion against the registered app identity.
• Extend the application configuration model with an optional attestation block (platform, app IDs, key IDs that Thunder accepts).
• Wire attestation verification into the HTTP new-flow path in loadNewContext(), consistent with the SPA guard (Implement HTTP guard in loadNewContext() to block direct flow initiation for authorization_code grant type applications #3215) and the App Secret check (Add App Secret verification for backend applications at flow initiation #3451). Reject new-flow initiation when attestation is required but missing or invalid, with a descriptive error.
• Continuing an existing flow with a known executionId is unaffected.

iOS — Apple App Attest

• Verify the App Attest assertion against Apple's keys/API, checking the registered app ID, team ID, and bundle ID.

Android — Google Play Integrity

• Verify the Play Integrity token against Google's verification API, checking the registered package name and signing identity.

Research / open items

• Confirm whether current mobile SDKs support the required redirections and server-side checks before finalising the integration design.
• Consider the CIBA intersection raised in the discussion (binding attestation to auth_req_id, TTL coherence, notification-initiated cold-start flows) — see [Design Discussion] Client-Initiated Backchannel Authentication (CIBA) #2740.

Acceptance Criteria

• A backend attestation configuration can be set on an application (platform, app/bundle IDs, key IDs).
• A POST /flow/execute new-flow initiation from a mobile client succeeds only with a valid attestation assertion for the configured platform and is rejected otherwise with a descriptive error.
• Both Apple App Attest and Google Play Integrity assertions are verified server-side against the registered app identity.
• Existing flow continuation via executionId is unaffected.
• The check is enforced at the service layer, not only at the API handler.