Timecode: nominal fps + proper drop-frame detection, shell-safe plan output; streams never VFR-re-encoded; gap list in the sidecar; docs

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

README.md

@@ -315,6 +315,12 @@ 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.
+
 ## Layout on the server
 
     /srv/media/streams/<user>/<Title>/.live/<ts>.mp4             recording in progress (hidden from Jellyfin/copyparty)