revert(auth): the newest registration does not own an unverified account (E9.5 review round 2)

Round 1 fixed the address pre-emption chain by letting a later registration replace the password on
an unverified account and delete its outstanding verify tokens. Round 2 read that code and showed it
was worse than what it fixed, so it goes back out.

It closes nothing. The rule is symmetric and an attacker can simply register last — on a timer,
inside the five-per-five-minutes budget — while the owner registers once. What it does add is two
primitives an unauthenticated caller did not have: overwrite a real registrant's chosen password,
and delete the confirmation link already sitting in their inbox (the approval mail's 7-day token is
an ordinary verify token, so the blanket delete took that too). Worst of all it fired on the rows
SEC-10 left stripped — password_hash NULL, password_revoked_at set, active — installing an
attacker's password where the entire state means "there is none", and clearing the stamp that is the
only reason password-reset still accepts them. That is a straight takeover which did not exist
before, in the code written to prevent one.

The owner's recourse needed no new primitive and already worked: password-reset accepts a
pre-empted account, proves the mailbox, rewrites the hash and bumps the session epoch. What remains
is the bounded window between a confirmation click and that reset, which is SEC-16 — logged with
this attempt written down, so the next person does not reach for it again.

Two smaller round-2 findings go with it. `upsert_pending_invite`'s new exact-spelling tie-break ran
before any status preference, so it could deterministically pick a DENIED sibling over a pending one
and reopen it — the very outcome its comment claimed to prevent; the status preference now comes
first. And `send_invitation` activated the account before the send it might have to report as
failed, so a request the UI called a failure had quietly let someone in; activation now follows a
mail that actually left. The verify token minted to render that mail still commits either way — it
is single-use, expires on its own and was mailed nowhere, and the note says so rather than leaving
the next reader to wonder whether it was missed.

backend/app/routes/admin.py

@@ -143,12 +143,12 @@ def _activate_user_by_email(db: Session, email: str) -> None:
     S1 justified that by saying `password_login` refuses an unverified account BEFORE it looks at
     `is_active`, so a pre-emptor could not sign in "approved or not". A review of the finished epic
     showed that argument only holds while the address stays unverified — and S6's approval mail
-    hands the real owner a confirmation link precisely so they will end that state. What actually
-    guards this now is `_register_account`: while an address is unverified the NEWEST registration
-    replaces the password and kills the outstanding verify tokens, so the real owner takes the
-    account back by registering, and a pre-emptor's password is only ever as good as the owner's
-    silence. The residual (an owner who confirms without ever registering or resetting) is logged
-    for E12 beside SEC-15. The revoke also stays on the Google-adoption path
+    hands the real owner a confirmation link precisely so they will end that state. Nothing replaced
+    the revoke, and that is deliberate: round 2 of the same review tried "the newest registration
+    owns an unverified account" and reverted it, because the rule is symmetric — an attacker can
+    always register last — and it handed anonymous callers a write onto a real account's credential.
+    The owner's recourse is password-reset, which proves the mailbox, rewrites the hash and bumps
+    the session epoch. The residual is logged as SEC-16. The revoke also stays on the Google-adoption path
     (auth.revoke_preset_password_if_unverified), where ownership is actually attested."""
     # Canonical, with the literal spelling preferred when both exist: approving
     # `npeter83.temu@gmail.com` must activate the account that registered as `npeter83temu@gmail.com`,
@@ -299,10 +299,6 @@ def send_invitation(
         # but a button the admin pressed must not answer with a success toast for a mail that was
         # never sent.
         raise HTTPException(status_code=409, detail={"code": "invite_send", "reason": "email_off"})
-    # Same as the other two paths that decide for an address (`approve_invite`, `add_invite`): an
-    # approved row means this mailbox may come in, so finish it. Without this the mail can promise
-    # "your account is ready — just sign in" to someone `password_login` will refuse for `is_active`.
-    _activate_user_by_email(db, inv.email)
     link, has_account, hours = _welcome_mail_parts(db, inv.email)
     # An explicit pick from the dialog is recorded, so a later mail to this address matches the one
     # the admin already sent. Only the explicit pick — writing the fallback back would turn a column
@@ -317,10 +313,21 @@ def send_invitation(
     # exists to answer "did I already write to them?", and the UI dims the button and warns about a
     # second mail on the strength of it. Stamping it before a send that then failed makes the one
     # question it answers a lie, and talks the admin out of the retry that would fix it.
+    #
+    # One thing a failed send does leave behind: the confirmation token `_welcome_mail_parts` minted
+    # to render the link, which commits inside `_issue_token`. Accepted rather than chased — the
+    # token is single-use, expires on its own, and was mailed nowhere; deferring it would mean
+    # rewriting a helper three callers share so the handler owns its commit.
     if not email_mod.send_access_invitation(inv.email, lang, link, has_account, hours):
         raise HTTPException(
             status_code=422, detail={"code": "invite_send", "reason": "send_failed"}
         )
+    # Only after the mail is actually out. Same as the other two paths that decide for an address
+    # (`approve_invite`, `add_invite`): an approved row means this mailbox may come in, so finish it,
+    # or the mail can promise "your account is ready — just sign in" to someone `password_login` will
+    # refuse for `is_active`. Doing it BEFORE the send would mean a request the UI reports as failed
+    # had quietly activated an account behind the admin's back.
+    _activate_user_by_email(db, inv.email)
     inv.invited_at = datetime.now(timezone.utc)
     audit.record(
         db,