fix: prevent buffer overruns from destroying stream start position

[chrisuthe]

Summary

• Pre-playback overrun safety net: When the buffer fills before playback starts (server's initial burst), discard incoming audio instead of dropping oldest. Preserves the stream's starting position so all players begin at the same point.
• SkipStaleAudio on late start: When a player's pipeline initializes late and the scheduled start time is in the past, skip forward through stale audio to the correct position instead of playing from the beginning of the buffer.
• Buffer capacity: Increase default from 30s to 120s (~44MB) with 60s minimum enforcement, preventing stale user configs (e.g., old 8s value) from causing undersized buffers.
• Dynamic BufferCapacity: Derive buffer_capacity in client/hello from actual PCM buffer duration × worst-case codec bitrate, instead of hardcoding 32MB.

Root cause

OPUS frames are tiny (~640 bytes/20ms) so the server blasts 40+ seconds of audio in seconds on LAN. With an 8s buffer (stale user config), 1746 overruns destroyed the beginning of the song. The player's scheduled start anchored to audio from 12.8s into the song, waited 12 seconds of silence, then started from ~35s — while the FLAC player started from 0s. The 22-second gap matched the buffer depth difference.

Test plan

• Two Windows clients (FLAC + OPUS) in same group start from the same position
• Player joining late (slow pipeline init) skips to correct position via SkipStaleAudio
• Stale user config with small CapacityMs is overridden by 60s minimum
• Logs show Buffer: Xms PCM → Y.ZMB advertised to server on startup
• No regressions in single-player playback or track changes

🤖 Generated with Claude Code