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_plex_hls_file_route.py

@@ -5,11 +5,11 @@ seek-restart — or a second viewer of the same item — replaces the registered
 viewer's next request for `seg_12.ts`, resolved by rating_key, was answered 200 with the NEW
 session's twelfth segment: bytes produced from a different `-ss` offset under `-copyts`, i.e. a
 timeline the client is not on. Wrong content with a success status is the one failure a player cannot
-notice, and the reclaim-on-404 added in round 4 could never fire on it (deep-review round 5).
+notice, and the client's reclaim-on-404 could never fire on it.
 
 No `db` fixture: the route reads nothing from the database (its own `Depends(get_db)` went with the
 removed auto-start, and `current_user` is overridden wholesale), so these must not sit in the DB
-lane — there they SKIP on a machine with no Postgres while pytest prints green (round 6).
+lane — there they SKIP on a machine with no Postgres while pytest prints green.
 """
 
 import time
@@ -127,7 +127,7 @@ def test_a_segment_that_will_never_arrive_fails_at_once(client, tmp_path, sessio
     """`stream_hls_file` is a SYNC route: it runs on the ~40-slot threadpool and holds a pooled DB
     connection while it waits. It used to poll out the whole 20 s for a name that could never appear
     — an ordinary seek past the produced region was enough to park a worker and a connection, and
-    forty hopeless names parked the API (deep-review round 5). ffmpeg writes segments in order, so a
+    forty hopeless names parked the API. ffmpeg writes segments in order, so a
     segment whose predecessor is absent is not the next one, and that is knowable at once — even
     while ffmpeg is still running, which is the case `proc` alone cannot shorten."""
     d = tmp_path / "m1_0_0_+0.00"
@@ -152,11 +152,11 @@ def test_a_segment_that_will_never_arrive_fails_at_once(client, tmp_path, sessio
 def test_a_multi_audio_segment_beyond_the_region_fails_at_once_too(
     client, tmp_path, sessions, name
 ):
-    """The round-5 guard read `seg_<seq>_<variant>.ts`, but ffmpeg substitutes `%v` FIRST — so the
+    """An earlier guard read `seg_<seq>_<variant>.ts`, but ffmpeg substitutes `%v` FIRST — so the
     real names are `seg_<variant>_<seq>.ts` and every multi-audio request fell through to the full
     20 s wait: the video rendition because its variant "0" parsed as segment 0, the audio renditions
     (`a0`, `a1`) because they did not parse at all. Dual-audio is the common shape in this library,
-    so the guard was inert exactly where it was needed (round 6)."""
+    so the guard was inert exactly where it was needed."""
     d = tmp_path / "m1_0_multi_+0.00"
     d.mkdir()
     (d / "seg_0_0.ts").write_bytes(b"x")
@@ -261,7 +261,7 @@ def test_the_name_ffmpeg_is_asked_for_is_a_name_the_guard_understands(tmp_path,
 def test_the_argv_asks_for_exactly_the_names_the_guard_accepts(tmp_path):
     """The producer and the parser, pinned to each other through the argv itself.
 
-    Round 6's HIGH was a guard that read `seg_%v_%d.ts` sequence-first, so it was inert on every
+    The bug was a guard that read `seg_%v_%d.ts` sequence-first, so it was inert on every
     multi-audio item, and a warm-up that waited 8 s for a name ffmpeg never writes. The fix was to
     give the layout one spelling — but a comment saying so is what had just failed, so assert that
     the `-hls_segment_filename` pattern in the real argv is literally what `segment_name` produces,
@@ -302,7 +302,7 @@ def test_a_name_only_the_other_argv_branch_writes_is_refused_at_once(tmp_path, c
     it can never write — and vice versa. Accepting the union read them as "an HLS name, so wait and
     see", and each one then held a threadpool worker and its pooled DB connection for the full
     timeout: measured through this route against a live single-audio session, `master.m3u8` took
-    30.0 s and `seg_a0_0.ts` 20.1 s to answer 404 (deep-review round 7)."""
+    30.0 s and `seg_a0_0.ts` 20.1 s to answer 404."""
     single = tmp_path / "m1_0_0_+0.00"
     single.mkdir()
     sessions[(VIEWER, "m1")] = _Session("sid-a", single, running=True)