fix(plex): a seek during a quiet reclaim is no longer undone

A quiet request leaves `live` alone, so a seek inside the old session's
range went native and the answer then jumped back to where it asked from.
`seek` now also goes by `pending`; the server-away retry had the same hole.

Comments that still named 404 for a lost session say 410, and the hls.js
retry comment now tells a finished playlist from a growing one.

backend/tests/test_hls_reaper.py

@@ -138,7 +138,7 @@ def test_the_periodic_pass_still_reaps_what_nobody_has_touched_for_the_idle_limi
 
 
 def test_every_reap_says_which_rule_took_the_session(tmp_path, sessions, caplog):
-    """A session that vanishes leaves the viewer a 404 and nothing else: with no line here, a live
+    """A session that vanishes leaves the viewer a 410 and nothing else: with no line here, a live
     stall could only ever be blamed on the reaper by inference."""
     sessions["1"] = _Session(
         tmp_path, "gone_done", finished=True, idle_s=stream._SESSION_IDLE_S - 5

backend/tests/test_plex_hls_file_route.py

@@ -5,7 +5,7 @@ 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 client's reclaim-on-404 could never fire on it.
+notice, and the client's reclaim 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