Sign in with Apple fails with ASAuthorizationError 1000 / AKAuthenticationError -7003 on a new App ID — server rejects the SRP exchange while other apps succeed on the same device

Sign in with Apple never completes for our app. The authorization sheet presents, the user confirms, and we get ASAuthorizationError 1000. The akd log shows the local entitlement check PASSING and the failure happening server-side.

Environment: native ASAuthorizationAppleIDProvider (no web flow, no Services ID), TestFlight build, iOS 26. New App ID created 2026-08-06.

akd, abridged — local check passes:

akd  Requesting password only: NO
akd  Client has default access level in SiwA entitlement
akd  Client has underage-users access level in SiwA entitlement

sheet presents, user confirms:

akd  presenting authorization UI for request
akd  Remote view sent a user response event
akd  Attempting authorization with response

then the server rejects it, after returning HTTP 200:

akd  Adding passwordlessToken: NO, and idmsDataToken: NO, to auth-params
akd  No password, but CK is available. Will ask for ck-based auth.
akd  Performing SRP request with context
akd  Task ... received response, status 200 content K
akd  AppleIDAuthSupport: setError: 2:M2 missing (bad password)
akd  Invalid/missing value for key acname: (null)
akd  SRP authentication with server failed! Domain=com.apple.AppleIDAuthSupport Code=2
akd  Error performing auth request: Domain=AKAuthenticationError Code=-7003

What we have already ruled out:

1. Sign in with Apple enabled on the App ID, configured as "Enable as a primary App ID" (verified in the portal UI, not just via the App Store Connect API).
2. Provisioning profiles deleted and regenerated AFTER enabling the capability, twice, the second time a full day later. The embedded .mobileprovision in the shipped build contains com.apple.developer.applesignin = (Default).
3. The signed binary carries the entitlement (codesign -d --entitlements on the archive).
4. More than 24 hours elapsed since enabling the capability, per the guidance on -7003 in thread 789697.
5. requestedScopes tried as both [.email] and [.fullName, .email].
6. App deleted and reinstalled; device restarted.
7. Reproduced on a SECOND device (an iPad) that had never had the app installed.
8. Control: a third-party App Store app created a brand-new Sign in with Apple association (it prompted for name, so first-time consent) on the same device and same Apple ID, minutes after our failure, so the account and device can create new associations.

Question: what causes Apple's identity service to reject the SRP exchange for one client while accepting it for others on the same device and account? Is there additional App ID or account state we cannot see from the portal?

Happy to provide the full akd log.