[derekmwright]

The WASAPI worker promotes itself with audio_thread_priority::promote_current_thread_to_real_time, but boost_current_thread_priority discards the returned RtPriorityHandle (Ok(_) => Ok(())). The handle has no Drop, so AvRevertMmThreadCharacteristics is never called for a stream's worker.

This change keeps the handle in a guard that lives on the worker for the whole run loop and reverts it on that same thread when the worker exits: normal stop, run-loop and device errors, early returns, and unwinding from a panic in a callback. A failed registration creates no guard, and the existing SetThreadPriority fallback is unchanged. A failed revert is reported through the stream's error callback on a best-effort basis: not while panicking, and not if the callback's mutex is contended.

Input and output workers both go through one priority::run(acquire, body) prologue, so the guard's lifetime is covered by unit tests rather than only by device runs.

Testing:

• cargo test --lib with and without the realtime feature on Windows: 18 passed. Clippy matches the base in both feature modes.
• Real devices, Windows 11, this branch: three output and three input opens through WASAPI, at least 32 callbacks each. Each worker registered once before its first callback and released once on close, with no stream errors. This checks registration and release only, not latency.

Not covered: ALSA and PipeWire call the same helper and appear to have the same issue, but their ownership model is different (rtkit), so they are left for a separate change.

[LastExceed]

Sry, but this is very over-engineered and copypasty.

[derekmwright]

I can pare down a much smaller fix for this if you'd like me to resubmit. The leak is still there and should be fixed. The agent was using my own standards around testing and didn't fully respect this repos style/submission guidelines.

[LastExceed]

Feel free to do so. Just please review the code yourself before submitting it.