fix: survive mumble disconnects without restarting audio stream

Guard stream_audio with _is_audio_ready() so that PCM frames are
dropped (not crashed on) when pymumble recreates SoundOutput with
encoder=None during reconnect. The ffmpeg pipeline stays alive,
position tracking remains accurate, and audio feeding resumes once
the codec is negotiated. Listeners hear brief silence instead of
a 30+ second restart with URL re-resolution.

Also adds chat messages to _auto_resume so users see what the bot
intends ("Resuming 'X' at M:SS in a moment" / "...aborted").

docs/USAGE.md

@@ -1605,9 +1605,24 @@ automatically resumes playback -- but only after the channel is silent
 - Works across container restarts (cold boot) and network reconnections
 - The bot waits up to 60s for silence; if the channel stays active, it
   aborts and the saved state remains for manual `!resume`
-- No chat message is sent on auto-resume; playback resumes silently
+- Chat messages announce resume intentions and abort reasons
 - The reconnect watcher starts via the `on_connected` plugin lifecycle hook
 
+### Disconnect-Resilient Streaming
+
+During brief network disconnects (~5-15s), the audio stream stays alive.
+The ffmpeg pipeline keeps running; PCM frames are read at real-time pace
+but dropped while pymumble reconnects. Once the connection re-establishes
+and the codec is negotiated, audio feeding resumes automatically. The
+listener hears a brief silence instead of a 30+ second restart with URL
+re-resolution.
+
+- The `_is_audio_ready()` guard checks: mumble connected, sound_output
+  exists, Opus encoder initialized
+- Frames are counted even during disconnect, so position tracking remains
+  accurate
+- State transitions (connected/disconnected) are logged for diagnostics
+
 ### Voice Ducking
 
 When other users speak in the Mumble channel, the music volume automatically