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/tests/test_playlist_position_lock.py

@@ -1,4 +1,4 @@
-"""E28 review — every request that reads a playlist's item positions and writes new ones locks the
+"""Every request that reads a playlist's item positions and writes new ones locks the
 playlist row first.
 
 Without it two adds (two tabs; the rail and the page) both read the same `max(position)` and land
@@ -7,7 +7,7 @@ rows is then whatever the planner returns. A true two-connection race is not rep
 demand, so the test holds the mechanism: the parent row is taken `FOR UPDATE` by each such route.
 A Plex reorder that omits a row (added in another tab meanwhile) must not collide with it either.
 
-Round 2: the lock also comes FIRST — before the request reads or writes a single item row. A remove
+The lock also comes FIRST — before the request reads or writes a single item row. A remove
 that deleted an item and then touched the playlist beside a reorder that went the other way was a
 deadlock (a 500 for one of them), and an add that checked "already there?" before the lock let two
 adds of one video both insert (a 500 on the unique key).