Fix silent FFmpeg playback failures

[shiftybitshiftr]

Summary

• wait for the first valid Opus packet before reporting playback startup, and surface FFmpeg startup failures instead of silently ending streams
• distinguish unavailable media from transient upstream failures so queue and seek state roll back safely
• make cache writes atomic across FFmpeg completion and concurrent invalidation, and preserve actionable command errors
• sanitize interaction error reporting while retaining enough context to diagnose failures

Production evidence

Recent PCT118 failures for jDRTghGZ7XU and _osKm4gGOFo resolved the signed YouTube URL but FFmpeg immediately received HTTP 403. The previous stream factory had already resolved, so the later error was discarded and Discord received an empty stream.

A PCT118 image built from this commit with yt-dlp 2026.08.19 is running successfully. Replaying the exact failed media IDs through the deployed downloader and FFmpeg produced valid Opus/WebM output. The known age-gated original still fails explicitly, and its configured fallback produces valid output.

Validation

• 274 tests passed
• typecheck passed
• lint passed
• production build passed
• autoreview clean

[github-actions]

📦 🤖 A new release has been made for this pull request.

To play around with this PR, pull ghcr.io/museofficial/muse:pr-1339.

Images are available for x86_64 and ARM64.

Latest commit: a710188