auth/callback rejects dangling supabaseAuthId as takeover instead of rebinding — 79 legacy users latent-locked-out

Confirmed bug (researcher report pm/reports/researcher/2026-07-21-supabaseauthid-write-paths.md). auth/callback treats a DANGLING supabaseAuthId (stored value matching no live auth.users identity) as an account-takeover attempt and REJECTS with login-authid-conflict, instead of rebinding to the user's genuine current Google identity. Live impact: 1 student (Matías Fernández) locked out 5x on 2026-07-20 22:45-22:53Z; 79 live users total carry a dangling legacy authId (76 latent first-login lockouts, 0 ambiguous per db-mars). Pre-creation source is already correct (all paths leave authId NULL); these are legacy pre-placeholder-era rows (8 already healed by mig 075). FIX: callback rebinds a dangling authId to the incoming verified Google sub ONLY when — genuine-Google identity (existing isGenuineGoogleUser gate) AND stored authId matches NO live auth.users identity AND canonical-email maps to exactly one live users row. If stored authId matches a DIFFERENT live identity → still reject (real conflict). Makes the 76 latent self-heal on first login, no data mutation, no recurrence. Class-A auth-gate: audit design-ping pre-impl + diff review pre-push + full PTD. Reversible (one commit). Interim: db-mars NULLs the 3 actively-blocked on Elazar GO to unblock tonight. GATED on Elazar GO (asked).