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/models.py

@@ -47,7 +47,8 @@ class User(Base, TimestampMixin):
     email: Mapped[str] = mapped_column(String(320), unique=True, index=True)
     # argon2id hash for email+password login; NULL for Google-only / demo accounts.
     password_hash: Mapped[str | None] = mapped_column(String(255))
-    # When SEC-10 dropped a preset password (see auth.revoke_preset_password_if_unverified). Without
+    # When SEC-10 dropped a preset password on Google adoption (see the single caller of
+    # auth.revoke_preset_password_if_unverified; admin approval no longer revokes — E9.5 S1). Without
     # this trace a revoked account was indistinguishable from a Google-only one, so it failed the
     # password-reset eligibility check and could never be recovered — it could neither sign in nor
     # reset. Set = "had a password, lost it to the guard" -> reset-eligible. Cleared whenever a

backend/app/routes/admin.py

@@ -27,7 +27,6 @@ from app.models import (
     Invite,
     User,
 )
-from app.routes.auth import revoke_preset_password_if_unverified
 from app.utils import iso, valid_email
 
 router = APIRouter(prefix="/api/admin", tags=["admin"])
@@ -88,13 +87,18 @@ def list_invites(
 
 def _activate_user_by_email(db: Session, email: str) -> None:
     """Approving access activates a matching (e.g. pending password-registration) account so
-    it can sign in. No-op if no such user exists yet (a Google user is created at first login)."""
+    it can sign in. No-op if no such user exists yet (a Google user is created at first login).
+
+    E9.5 S1: this path deliberately does NOT revoke a preset password. Approval is not an ownership
+    attestation, and it does not need to be one — `password_login` refuses an unverified account
+    BEFORE it looks at `is_active`, so a pre-emptor who set a password on someone else's address
+    still cannot sign in with it, approved or not. Revoking here only ever destroyed the password a
+    legitimate registrant had just chosen, and made "your password was cleared for security" the
+    DEFAULT experience, because approve-before-verify is the normal ordering. The revoke stays on
+    the Google-adoption path (auth.revoke_preset_password_if_unverified), where the real owner does
+    attest ownership and the preset password must not survive."""
     user = db.execute(select(User).where(User.email == email.lower())).scalar_one_or_none()
     if user is not None and not user.is_active:
-        # SEC-10: same guard as the Google-adoption path — approving an account whose email was never
-        # verified must not hand a working login to a password set on it by whoever registered the
-        # address (a pre-emption). Shared single-source helper so the two paths can't drift.
-        revoke_preset_password_if_unverified(user)
         user.is_active = True
         db.commit()
 

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