files: seek anywhere in a re-encode; it restarts from there

A re-encode's playlist is now the whole film on a fixed 4 s grid. A segment
that isn't on disk and isn't coming soon moves the encode there; runs stop
short of segments already made, and gaps are filled after. Every run is cut
the same way (-ss, -output_ts_offset start+10, frag_discont), so segments
from different runs join. Repackaging keeps its growing playlist.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

PLAN.md

@@ -772,9 +772,38 @@ something long in one, switch away and back, refresh — it's all still there.
     11.7×, AV1 720p 13×, all on the Arc. `core` and `hamtv` re-encode on the CPU until
     *Allow GPU access* is pressed (libx264 at 9.4× for a 720p→480p clip on `core`); the Mac
     and `gate` need ffmpeg first, which the previews note offers to install.
-  - *Not done, on purpose:* no restart-from-a-seek beyond what is encoded (the encode is
-    faster than watching; a seek far ahead waits), no bit-rate ladder or adaptive
-    switching, no subtitles, no keeping a finished re-encode for next time.
+  - *Not done, on purpose:* no bit-rate ladder or adaptive switching, no subtitles, no
+    keeping a finished re-encode for next time. (Restart-from-a-seek was left out here at
+    first; it came 2026-10-20, the next entry.)
+- **Seek anywhere in a re-encode** — **2026-10-20**. Asked for as "there's no way to seek in
+  the video and have the service just start transcoding from that point onward".
+  - **The playlist is the whole film, up front:** a VOD playlist on a fixed 4 s grid
+    (`segCount`, the last 0.3 s left out so sound running past the picture never lists a
+    segment no frame starts), so the seek bar is the film's from the first frame.
+  - **A segment not on disk** is waited for when the run going now will write it within 3
+    segments; otherwise it is a seek: that run is ended and one starts at the segment asked
+    for. A run stops half a frame short of the next segment already on disk, never over it.
+    When a run ends by itself the next gap is filled, wrapping round, until every segment is
+    there. The newest request moves the run; an older one still waiting never moves it back.
+    A run we end closes its half-done segment short on the way out, so whatever it finished
+    after being asked to stop is deleted.
+  - **Runs are interchangeable** because every one, the first included, is made the same way
+    (`segArgs`): accurate `-ss` to the segment, timestamps put back with
+    `-output_ts_offset start+10` (the +10 keeps every run clear of the muxer's shift for the
+    B-frame delay, which a run from the top would otherwise get and a seek wouldn't), kept
+    absolute in each fragment (`movflags=+frag_discont`), `-start_number`. Tested on MKV
+    and on MPEG-TS with a 2.8 s start time (where `-copyts` was a second out): the init
+    segments come out byte-identical, and a seeked run's segments join a from-the-top run's
+    within a frame. Only the first run's init is served; a later run writes `init-run.mp4`
+    and the log notes if it ever differs.
+  - Repackaged ("copy") streams keep the growing event playlist: the source's keyframes
+    don't sit on a grid, and repackaging is near-instant anyway.
+  - A segment waits at most 45 s, under the hub proxy's 60 s for a node to answer; hls.js
+    is told a segment's first byte may take 50 s. The bar reads "7.3× from 12:00 · 43%
+    ready — seek anywhere".
+  - Tested (`TestSeekRestartsTheEncode`): a 64 s 1080p clip, a request for segment 12 right
+    after the start runs from 48 s, the gap is filled, all 16 segments joined behind the one
+    init decode with no hole.
 - **Files edge sweep** — **2026-10-11** (v0.1.0-214), asked for as "a full bug sweep of
   the Files section, every example and edge case". Every handler and both UI files read
   through with odd inputs in mind, then a battery of ~60 requests against the live hub