fix: recover from WASAPI device invalidation instead of going silent

[chrisuthe]

The bug (from a live log)

Playback went permanently silent. The log showed:

[ERR] WasapiAudioPlayer: Playback stopped due to error
System.Runtime.InteropServices.COMException (0x88890004)
   at IAudioClient.GetCurrentPadding
   at WasapiOut.PlayThread()
Player state: "Playing" -> "Error"
…
[Buffer] Overrun #2640: dropped 96ms … buffer full at 120000ms   (forever)

0x88890004 is AUDCLNT_E_DEVICE_INVALIDATED — the output device was pulled out from under WASAPI (default device changed, device disabled/unplugged/reformatted, or grabbed in exclusive mode). The player dropped to a terminal Error state and never recovered; the network kept feeding the buffer, which pinned at capacity and just churned overruns with nobody reading. Silent until app restart.

Fix

Detect that HResult in OnPlaybackStopped and re-initialize the output on the current device, resuming from the buffered audio, instead of dying:

• Recovery reuses the existing device-switch rebuild path (which preserves the buffer and re-anchors timing), via a new internal forceResume flag.
• Retries up to 5× with a short increasing backoff so Windows can settle a new default device; only falls back to Error if every attempt fails.
• The previous output's Stop() is now guarded — a dead/invalidated device throws on Stop().

Net effect: a device change that used to silence playback forever becomes a brief blip that self-recovers.

Scope / risk

App-only, independent of the SDK PRs. No change to the normal Clear()/play paths; the only edit to the device-switch path is the additive forceResume parameter and the guarded Stop().

Verify

Manual (it's a hardware/OS event): play audio, then in Windows Sound settings change the default output device (or disable the playing device). Expect a ~½–1s gap, then audio resumes and the log shows Recovered audio output after device invalidation. Build green, 99/99 tests pass.