chore(comments): drop epic, sprint and review-round ids from the code

The code cited its plan instead of saying why: `E28 review J4`, `(R6 S3b)`, `S1 justified…`,
`deep-review round 5`. That plan lives in the private ops repo, so for every reader of this one the
citation was noise, and a sentence whose subject was the plan step ("round 2 showed…") hid its
lesson behind an id. Each one is gone and the "why" kept: a bare citation is deleted, a sentence
carrying a lesson is reworded around it ("a later attempt showed…").

Measured (`scripts/audit_metrics.py`, product code): 652 lines in 270 files carried an epic code by
the definition the next commit holds (507 / 241 by the old, two-digit-only one) -> 0. Across all
code, tests, scripts and configs: ~1100 epic-code lines plus ~320 sprint/round ids.

Behaviour unchanged, checked mechanically: every changed .py file has the same AST once docstrings
are blanked; css/sh/toml/yml/json files are identical once comments are stripped; the only
non-comment changes in TS/JS are test titles, one description string in a contract table, and five
ESLint messages, whose text is all the gates snapshot diff holds. Not touched: Markdown (docs and
the changelog keep their history), Alembic migrations, TV episode notation (`S2 · E5`), DESIGN.md
ids (`C1`, `B4`, `S3h`), tracker ids (`SEC-16`, `DX-17`).

One stale claim fixed on the way: test_hls_reaper's docstring said the player checkpoints "every
10 s whether or not it is playing", which plex/stream.py calls wrong; it now says what the code does.

backend/app/routes/admin.py

@@ -138,20 +138,21 @@ 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).
 
-    E9.5 S1: this path deliberately does NOT revoke a preset password. Revoking here destroyed the
+    This path deliberately does NOT revoke a preset password. Revoking here 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.
 
-    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. 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."""
+    That was once justified 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 the
+    approval mail hands the real owner a confirmation link precisely so they will end that state.
+    Nothing replaced the revoke, and that is deliberate: the same review later 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`,
     # since Gmail delivers both to one mailbox and the admin decided about the mailbox.
@@ -402,7 +403,7 @@ def _serialize_user(u: User) -> dict:
         # deciding what kind of help someone needs.
         "password_revoked_at": iso(u.password_revoked_at),
         "has_google": u.google_sub is not None,
-        # Only when it DIFFERS from the account address (E9.5 S3): "connected" is not the same
+        # Only when it DIFFERS from the account address: "connected" is not the same
         # statement as "connected as someone else", and the second one is the one that explains a
         # confusing sign-in.
         "google_email": u.google_email if u.google_email != u.email else None,
@@ -551,7 +552,7 @@ def admin_delete_user(
     return {"deleted": user_id}
 
 
-# --- Stuck sign-ups: the admin lifeline (E9.5 S5, roadmap UX-25) ---------------------------------
+# --- Stuck sign-ups: the admin lifeline -----------------------------------------------------------
 
 
 def _pending_access_rows(db: Session) -> list[User]:
@@ -609,7 +610,7 @@ def user_access(
     _: User = Depends(admin_user),
     db: Session = Depends(get_db),
 ) -> dict:
-    """Everything the account panel shows about why this person can or cannot get in (E12 S5).
+    """Everything the account panel shows about why this person can or cannot get in.
 
     Its own endpoint rather than extra columns on /users: `is_allowed` and `can_activate` each run a
     query, and the panel opens for ONE user at a time — folding them into the list would pay that cost
@@ -628,7 +629,7 @@ def create_set_password_link(
     admin: User = Depends(admin_user),
     db: Session = Depends(get_db),
 ) -> dict:
-    """Mint a one-time link that lets this account set a password, with no email involved (E12 S5).
+    """Mint a one-time link that lets this account set a password, with no email involved.
 
     The answer to SEC-15, SEC-16 and "no SMTP and someone forgot their password" at once. The admin
     hands the link over by whatever channel they trust; opening it sets a password and signs out