Sign in with Apple fails with "Sign Up Not Completed" after native Apple dialog — reproducible on iPhone AND iPad, all config verified correct

App: AGEX (bundle co.median.ios.eezoqmk), using the auth flow via lovable.auth.signInWithOAuth("apple", { redirect_uri }) which triggers Median's native Sign in with Apple bridge.

Symptom: Tapping "Continue with Apple" correctly opens Apple's native consent sheet (name/email sharing options). After tapping "Continue", Apple's own system UI shows an error: "Sign Up Not Completed" with a "Use a different Apple ID" link — before any request ever reaches our backend (confirmed via Supabase Auth logs: zero Apple-related entries, success or failure, during multiple test attempts).

Reproduced consistently:

On iPhone AND iPad
- With "Share My Email" AND "Hide My Email"
- - Across multiple attempts over ~2 hours with the same Apple ID
  - - After a fresh iOS build (config change to Link Handling rules, adding an Internal rule for our Supabase auth callback domain) — no change in behavior
  - Verified as correct (screenshots/checks available):
  - - App ID (co.median.ios.eezoqmk): "Sign In with Apple" capability enabled, configured as Primary App ID, no errors shown
    - - Services ID (world.agex.web): correctly configured with Domains = our Supabase project domain, Return URL = our Supabase auth callback
      - Supabase Auth provider (Apple): enabled, Client ID matches Services ID exactly, Client secret (JWT) present and not flagged as expired
        
        Median Link Handling: appleid.apple.com and our Supabase auth domain are both set to "Internal"
        
        This also caused an App Store rejection today under Guideline 2.1(a) (App Completeness) — Apple's own reviewer reproduced the same bug on an iPad Air (M3).
      - I found a related unresolved thread on this forum about "Why does the Sign in with Apple bridge not request name and email?" (different symptom — nulls returned instead of a hard failure — but same underlying Sign in with Apple bridge). Wondering if these share a root cause in the bridge itself.
    - Any guidance on what could cause Apple's own system to reject the sign-in attempt this early (before any callback), given the config above looks correct? Is there a way to check the actual private key