fix(audio): release the device before reopening it exclusively

[InstaZDLL]

Addresses the reproducible half of #604.

What the logs actually say

0x8889000A is AUDCLNT_E_DEVICE_IN_USE, and the question was who held the
device. Three facts, measured on Windows 11 with a throwaway probe rather
than reasoned about:

Question	Answer
Does a shared client of ours block our exclusive open?	No. Initialize in exclusive mode succeeds while one of our own shared streams is open and running on the same endpoint.
Does an exclusive client block it?	Yes, with exactly 0x8889000A.
How long does the block outlive the client?	~19 ms after the drop.

The third one matters because it rules out the leading hypothesis. A
release still in flight cannot explain a loop that ran for twelve seconds.
The holder was still alive.

Who was holding it

set_output_device opens the replacement stream before releasing the
old one, and says why: the two streams target different endpoints, so a
failed open costs nothing and playback survives. That premise is what a
vanished device breaks. pick_device falls back to the default
endpoint when the pinned name is no longer enumerated — which is precisely
the state after a Bluetooth headset disconnects — and that endpoint can be
the one the old exclusive stream is still holding. The open is then refused
against ourselves.

The rule for this already existed. must_release_before_reopening was
added for the same class of defect on macOS, and both force_rebuild_output
and set_exclusive_output consult it. The switch path never did.

A shared old stream still keeps the spawn-first order and the rollback it
buys, because the first measurement above says it is no obstacle.

A correction

The doc comment being touched here claimed Windows evicts the shared client
when the endpoint is seized. That was written from reasoning, not from a
run, and it is backwards in a way that mattered: it is exactly the sentence
that made a shared client look like the suspect. It now carries the
measurement instead.

The other commit

Clippy runs on the Linux slot only, on the stated grounds that its answer
cannot differ by operating system. True for portable code, false for code
behind a cfg: wasapi_exclusive.rs is never compiled where clippy runs,
so a needless_borrow sat in it from the day the shared period fill
landed. coreaudio_exclusive.rs has no job at all and is linted nowhere.
The lint is fixed here; whether to run clippy on the Windows slot is a
cost decision left to the maintainer, since the current arrangement is
documented as deliberate.

What this does not close

The reporter describes silence; the logs also show a storm of failed opens.
They are two distinct moments — 04:58 and 06:20 — and only one symptom was
reported. Nothing here establishes they share a cause, and #604 should stay
open until its author confirms.

The silent redirect itself is untouched: a pinned device that has vanished
still becomes the default one with only a log line to say so, and the
picker still shows the old selection. That is #597, and #604 is what it
looks like from the outside.

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

_{Comment @coderabbitai help to get the list of available commands.}