fix(auth): close what the epic's own review found (E9.5 review round 1)

Eleven findings survived adversarial verification; these are the fixes.

**Address pre-emption.** S1 dropped the approval-time password revoke, arguing `password_login`
refuses an unverified account before it reads `is_active`. Two verifiers showed that holds only
while the address stays unverified — and S6's approval mail exists to get the real owner to end that
state, at which point the squatter's password works. While an address is unverified the NEWEST
registration now owns it: the password is replaced and every outstanding verify token deleted, so
the owner takes the row back simply by registering, and a link already in flight cannot confirm it
for anyone else. The residual (an owner who confirms and neither registers nor resets) is logged as
SEC-16 beside SEC-15, where the re-attestation path it needs already lives. The comments that
asserted the old, false invariant now say what actually guards this.

**The entry URL.** S2 moved `clearEntryUrl()` out of the signed-out auth card into a hook App mounts
unconditionally, and it blanket-stripped the whole query string, the fragment and `history.state` on
the FIRST commit. That broke first-run setup outright — the wizard mounts only after its query
resolves and then finds no `?token=` — and silently ate `?link=`/`?oauth=` (no toast, no refetch
after connecting Google), `?v=`/`?chan=` deep links, and scroll restoration. It now clears only the
fragment and the two one-time flags it owns, and preserves `history.state`.

**The env allow-list.** S3 canonicalised the Invite branch of `is_allowed` and left the
ALLOWED_EMAILS/ADMIN_EMAILS fallback matching literally — the 2026-09-03 lockout with a different
source of truth, plus a shadowing trick where an unauthenticated request under a sibling spelling
permanently masked an env grant. Canonical on both sides now, and the same for the delete dialog's
warning and the ADMIN_EMAILS role bootstrap.

**Honest states.** `send_invitation` stamped "I already wrote to them" before a fail-soft background
send; it sends inline and records only what left. The admin-side resend answered `{ok: true}` for a
dropped mail; it now says so. Both also activate/serialize consistently with the other decide paths.

**Correctness sweep.** The 7-day approval link said "expires in 168 hours" — durations render in
days once there is more than one. `_register_account`, `upsert_pending_invite` and `add_invite`
picked among canonical siblings with no ORDER BY and no exact-spelling tie-break, so which account
got the re-send, and whether a denied row was reopened over a pending one, was up to Postgres.
`purge_user` deleted every canonically-equal invite, revoking a surviving sibling account's access.
`ConfirmProvider` wrapped its ReactNode message in a `<p>`. Approving no longer leaves the
stuck-sign-ups list stale. The refusal panels announce and take focus.

**Tests.** Three mailers rewritten this epic never rendered in any test; every `send_*` now renders
in both languages. The orphan-key guard could not fail (it scanned the catalog that defines the
keys) and had no reverse direction. Newly pinned: canonical activation, the surviving sibling's
grant, a failed invitation and resend, an expired reset link, a throttled login's silence, the
per-language admin fan-out, and that the entry URL keeps what it does not own.

backend/app/auth.py

@@ -65,6 +65,26 @@ def has_write_scope(user: User) -> bool:
     return WRITE_SCOPE in tok.scopes.split()
 
 
+def env_allowed_canonicals() -> set[str]:
+    """The env bootstrap allow-list, in CANONICAL form — the only shape it may be compared in.
+
+    S3 canonicalised the Invite branch of `is_allowed` and left this one matching the literal string,
+    which is the 2026-09-03 lockout with a different source of truth: an operator who writes
+    `first.last@gmail.com` into ALLOWED_EMAILS is refused when Google answers with the undotted
+    primary, and a `+tag`ged entry can never match at all, because a Google account cannot contain a
+    `+`. The addresses themselves stay literal wherever we MAIL them (`admin_notify_groups`); only
+    the comparison is canonical.
+    """
+    return env_admin_canonicals() | {canonical_email(e) for e in settings.allowed_email_set}
+
+
+def env_admin_canonicals() -> set[str]:
+    """The env ADMIN_EMAILS bootstrap list, canonical — for the role check only. Kept separate from
+    `env_allowed_canonicals` because being listed as an admin also grants access, but being allowed
+    does not make anyone an admin."""
+    return {canonical_email(e) for e in settings.admin_email_set}
+
+
 def is_allowed(db: Session, email: str) -> bool:
     """May this email sign in? An approved Invite is the source of truth; the env
     ALLOWED_EMAILS/ADMIN_EMAILS remain a bootstrap fallback (e.g. a fresh DB).
@@ -89,8 +109,7 @@ def is_allowed(db: Session, email: str) -> bool:
     )
     if statuses:
         return "approved" in statuses
-    email = email.lower()
-    return email in settings.allowed_email_set or email in settings.admin_email_set
+    return canon in env_allowed_canonicals()
 
 
 def can_activate(db: Session, user: User) -> bool:
@@ -226,10 +245,19 @@ def purge_user(db: Session, user: User, background: BackgroundTasks) -> None:
     )
     # Raw delete so Postgres applies ON DELETE CASCADE / SET NULL on every dependent table.
     db.execute(delete(User).where(User.id == user_id))
-    # Every canonically-equal invite goes, not just the literal spelling: is_allowed now matches on
-    # the canonical form, so leaving a sibling row behind would keep granting access to a mailbox
-    # whose account was just erased — and prod really does carry approved pairs for one mailbox.
-    db.execute(delete(Invite).where(Invite.email_canonical == canonical_email(email)))
+    # Every canonically-equal invite goes, not just the literal spelling: is_allowed matches on the
+    # canonical form, so leaving a sibling row behind would keep granting access to a mailbox whose
+    # account was just erased — and prod really does carry approved pairs for one mailbox.
+    #
+    # Unless ANOTHER account still lives on that mailbox — prod carries that too (two user rows for
+    # one Gmail mailbox). Then NO invite goes, not even the literal one: is_allowed matches
+    # canonically, so every row here is what keeps the survivor allowed, and removing any of them
+    # would refuse their next Google sign-in and reopen it as a fresh access request — this epic's
+    # founding bug, caused by its own cleanup. `delete_invite` refuses for exactly this reason; the
+    # user row is already gone by now, so this query sees only the others.
+    canon = canonical_email(email)
+    if db.execute(select(User.id).where(User.email_canonical == canon)).first() is None:
+        db.execute(delete(Invite).where(Invite.email_canonical == canon))
     db.commit()
     if google_token:
         background.add_task(revoke_google_token, google_token)