fix(auth): stop discarding a legitimate password on admin approval (E9.5 S1)

SEC-10 revoked any password set while an account's email was unverified, on both
the Google-adoption and the admin-approval path. On the approval path that was
redundant: password_login refuses an unverified account before it ever reads
is_active, so approval hands a pre-emptor's password nothing it could use. All the
revoke achieved there was destroying the password a legitimate registrant had just
chosen -- and since the admin normally decides before the user reads their mail,
'your password was cleared for security' was the DEFAULT experience, not an edge
case. The guard stays on the Google-adoption path, where the real owner does attest
ownership.

password_reset_required and the ok_reset banner stay: accounts stripped on prod
before this change have no other way back in.

Two existing tests pinned the old rule, so they are rewritten rather than deleted,
and the SEC-10 recovery pack now builds the revoked state through the surviving
producer.

backend/app/routes/auth.py

@@ -664,11 +664,13 @@ def verify_email_confirm(body: TokenIn, db: Session = Depends(get_db)) -> dict:
     """Confirm an email-verification token the SPA read from the URL fragment (SB3). Uniform 400
     on any invalid/expired/used token.
 
-    `password_reset_required` tells the SPA to send the user straight to the reset flow: an admin who
-    approved this account BEFORE it was verified tripped SEC-10, so the password chosen at registration
-    is gone and sign-in would answer with the deliberately uniform "Invalid email or password" — true,
-    but unreadable to the person who just proved they own the mailbox. Saying so leaks nothing: holding
-    a valid single-use verify token for this account already proves that much."""
+    `password_reset_required` tells the SPA to send the user straight to the reset flow: SEC-10 had
+    dropped the password this account registered with, so sign-in would answer with the deliberately
+    uniform "Invalid email or password" — true, but unreadable to the person who just proved they own
+    the mailbox. Saying so leaks nothing: holding a valid single-use verify token for this account
+    already proves that much. Since E9.5 S1 the common source of that state is gone (admin approval no
+    longer revokes), leaving accounts stripped before that change and the Google-adoption path, so this
+    flag is rare now — but it must stay, because those users have no other way back in."""
     user = _consume_token(db, body.token, "verify")
     if user is None:
         raise HTTPException(
@@ -859,10 +861,17 @@ def bump_session_epoch(user: User) -> None:
 def revoke_preset_password_if_unverified(user: User) -> None:
     """SEC-10 (account pre-emption): a password set on an account whose email was NEVER verified is
     untrusted — whoever registered the address (to pre-empt the real owner) could have chosen it. When
-    ownership is finally attested (Google adoption, or admin approval), drop that password and bump the
-    epoch to revoke any session it minted; the owner re-sets one via password-reset. No-op for an
-    already-verified account, so a legit no-SMTP registration is unaffected. The single source for this
-    rule — both the Google-callback and admin-activation paths call it so they can't drift.
+    the real owner attests ownership through Google, drop that password and bump the epoch to revoke any
+    session it minted; the owner re-sets one via password-reset. No-op for an already-verified account,
+    so a legit no-SMTP registration is unaffected.
+
+    The Google-adoption callback is the ONLY caller (E9.5 S1). Admin approval used to call this too, and
+    that was redundant: `password_login` refuses an unverified account before it even reads `is_active`,
+    so approval hands a pre-emptor's password nothing it could use. All the admin-path revoke achieved
+    was destroying the password a legitimate registrant had just chosen — and since the admin normally
+    decides before the user reads their mail, that made the "your password was cleared" detour the
+    DEFAULT path rather than an edge case. Keep it that way: if a second caller ever looks justified,
+    check first whether the gate it is guarding already runs earlier.
 
     `password_revoked_at` is what makes "the owner re-sets one via password-reset" actually true. The
     revoke leaves `password_hash IS NULL`, which is also what a Google-only account looks like — and