Sweep: opt-in gap filling for streams (FILL_GAPS_MS) — CFR re-encode with duplicated frames, raw kept in .src/, timecode carried; default off

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

README.md

@@ -315,11 +315,14 @@ Viewing: the live portal crops the band; Jellyfin shows it as a thin strip at th
 Cross-check when it matters: everyone is in the same voice chat, so audio-waveform sync is sample-accurate.
 Why continuous and not a start burst: a PC clock drifts vs the server (10 ppm ≈ 4 frames over 2 h).
 
-Dropped frames / gaps: OBS keeps stamping frames from its clock, so after a drop the file simply has a hole and
-every frame that exists is still at the right time — the timecode stays correct. The sweep **never re-encodes a
-stream** to fill holes (hours of CPU); the sidecar lists the gaps (`gaps.count`, `total_missing_ms`, first 50
-positions) so editors know where a clip may need a nudge. Premiere preserves timing on such files by default;
-in Resolve check "Timecode" interpretation on gappy clips. Clips (short) are still converted to constant frame rate.
+Dropped frames / gaps: OBS keeps stamping frames from its clock, so after a drop the file has a hole and every
+frame that exists is still at the right time — the timecode stays correct, and players (Jellyfin, the portal)
+hold the last frame across the hole with audio in sync. By default the sweep does **not** re-encode a stream to
+fill holes (hours of CPU on this box); the sidecar lists them (`gaps.count`, `total_missing_ms`, first 50
+positions). Premiere preserves timing on such files; in Resolve check the clip's frame-rate interpretation.
+Opt-in filling: `Environment=FILL_GAPS_MS=1000` in `normalize-sweep.service` makes the sweep re-encode any
+stream whose holes total ≥ 1 s to constant frame rate with duplicated frames (raw kept in `.src/`, timecode
+carried over). Sensible once the box has a hardware encoder (SYS-3). Clips are always converted to CFR.
 
 ## Layout on the server