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>

internal/config/config.go

@@ -92,6 +92,13 @@ type Player struct {
 	// feeds is unwatchable with sound, and skipping the audio decoder saves
 	// CPU per stream.
 	Audio bool `yaml:"audio,omitempty"`
+	// ResyncSeconds, when > 0, makes the daemon reconnect each stream to the
+	// live edge on this interval (staggered across tiles). Live RTSP can't be
+	// seeked, so latency that slowly accumulates when the Pi decodes a hair
+	// behind real-time is only cleared by reopening the stream. Each tile is
+	// resynced about once per interval; e.g. 600 keeps drift well under a few
+	// seconds. 0 = off.
+	ResyncSeconds int `yaml:"resync_seconds,omitempty"`
 	// RestartBackoffSeconds is how long to wait before relaunching a stream
 	// that exited or stalled.
 	RestartBackoffSeconds int `yaml:"restart_backoff_seconds,omitempty"`