App Attest assertions rejected as invalid by downstream validator on iOS 26.x — fleet-wide, pristine first-install devices

Symptom

Production iOS app (TestFlight) using App Attest. Devices generate assertions via DCAppAttestService (through Firebase App Check, which forwards to Apple's validation infrastructure). The fleet was attesting cleanly at ~100% verified for the first ~7 days post-first-install per device — then collapsed to ~0% verified once the initial token's natural TTL expired and devices were forced to re-attest. Has stayed at ~0% for 3+ days. Affects all 4 physical TestFlight devices; not reproducing on simulators (which is expected — App Attest unavailable there).

The downstream validator's metric specifically categorizes these as "invalid" — meaning a token reached it and was rejected as cryptographically invalid — not as "no token sent" / "unrecognized origin" / "outdated SDK."

Environment

• iOS 26.x (26.3.1 confirmed on multiple devices).
• Team ID T68SS8UY5J, bundle com.calimento.app, App ID has App Attest capability checked.
• Entitlements signed into binary: com.apple.developer.devicecheck.appattest-environment = production. Xcode would refuse this embed if the App ID lost the capability — so capability state is verifiably intact.
• Provisioning profile UUID byte-identical between the last verified-traffic build and the first invalid-traffic build (confirmed via Xcode build logs).
• Same code-signing identity hash across both builds.
• TestFlight builds approved by Apple Beta Review.

What's been ruled out

• Provisioning / signing / certificate drift (UUID and cert hash unchanged across builds).
• App ID capability revocation (entitlement embed succeeded).
• Firebase iOS app config drift (GoogleService-Info.plist byte-identical across vault, local working tree, and Firebase Console download).
• Token attachment / SDK init race (0% of requests in the "no token" or "outdated client" buckets).
• Pod / dependency drift (package-lock byte-identical between verified and failing builds).

The integration was producing valid assertions for ~7 days post-install per device — code-side bugs would have manifested from day one, not synchronized to the TTL boundary.

Questions

1. Are there known iOS 26.x server-side issues with App Attest assertion validation that would cause hardware-generated assertions to be rejected as cryptographically invalid?
2. Is there a documented or undocumented abuse-mitigation behavior that downgrades or invalidates assertions for an App ID under specific conditions — e.g., after a volume threshold within a window, or after a fingerprint anomaly? Looking specifically at whether high attestation churn during development can leave an App ID's attestation state in a degraded mode.
3. Is there any way to inspect Apple's reason for rejecting a specific assertion — through a developer tool, console log, or feedback channel? The downstream validator only surfaces"invalid"; it doesn't report Apple's underlying rejection reason.
4. Recovery semantics: if a device's keyId ends up internally blocklisted, does it age out, or is the device permanently unable to produce valid assertions for that App ID?
5. appattest-environment = production validation flow: any way the production environment validator could differ from development in a way that produces this signature?

Why I'm filing here rather than only with the SDK maintainer: The SDK is reliably attaching tokens (0% in the "no token" bucket). Origin is being recognized (0% in the "unknown origin" bucket). The rejection is happening at signature validation — which is downstream of any client-SDK behavior. Cross-filed with the React Native Firebase maintainers at [https://github.com/invertase/react-native-firebase/issues/9008]; if the root cause turns out to be on the wrapper's side, that thread will be closed.

Happy to provide raw build logs, validator metric exports, or a build for a test device on Apple's side privately.