Bound live-stream latency drift with periodic live-edge resync

Over hours the wall drifted ~15s behind real-time: the Pi decodes a hair
slower than real-time, and since RTSP-over-TCP delivers every byte, that
small deficit buffers up instead of being dropped — and a live stream
can't be seeked back to the live edge.

Add player.resync_seconds (0 = off): the daemon reconnects each stream to
the live edge on that interval via mpv loadfile-replace over IPC, cycling
one tile at a time so only a single tile ever blips. Reusing the running
mpv process means no window teardown. At 600s this caps drift to a couple
seconds. config.example.yaml ships it at 600; README documents the knob
and the "also lighten decode load" caveat.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

README.md

@@ -269,6 +269,13 @@ pegged, work through:
   of accumulating a backlog. Capping `player.max_fps` trims render load too.
 - **Audio is off by default** (`--no-audio`), which skips one audio decoder per
   stream. Set `player.audio: true` if you actually want camera sound.
+- **Latency slowly creeping up over hours** (e.g. seconds of drift after a
+  couple hours) means the Pi is decoding a hair behind real-time, so RTSP-over-
+  TCP quietly buffers the deficit — and a live stream can't be seeked back to
+  "now." Set `player.resync_seconds` (e.g. `600`) so the daemon reconnects each
+  stream to the live edge on that interval, staggered one tile at a time, which
+  caps the drift to a few seconds. If drift is large, also lighten decode load
+  (low substreams, cap `max_fps`) so the Pi keeps up between resyncs.
 
 ## Troubleshooting