Disconnect evicted capture streams before dropping them

[HoneyHazard]

⚠️ Full Disclosure: Drafted with AI assistance (Claude); reviewed by me briefly. I am neither a RUST developer nor pipewire expert. If I should stop making these PRs into your wonderful project, please let me know. ⚠️

That being said, I hope these can be helpful and useful additions that users could appreciate.

---

Found this while working on a separate feature that counts "wiremix-capture" nodes in the shared PipeWire graph - it kept seeing more capture nodes than wiremix's own bookkeeping (capturing_objects) accounted for, and it turned out to be a real leak, not a counting bug.

StreamRegistry::add_stream() evicts any existing stream already registered under the same stream_id before inserting the new one:

if let Some(old) = self.streams.insert(stream_id, stream) {
    self.garbage_streams.push(old);
    ...

StreamRegistry::remove() does the same eviction, but calls .disconnect() on the outgoing stream first:

if let Some(stream) = self.streams.remove(&stream_id) {
    let _ = stream.disconnect();
    self.garbage_streams.push(stream);
    ...

add_stream() was missing that .disconnect() call. Dropping the evicted StreamRc alone only destroys the client-side stream object - StreamBox's Drop impl calls pw_stream_destroy directly, never pw_stream_disconnect. Without an explicit disconnect first, the corresponding node can be left registered in the graph, invisible to wiremix's own state but still visible to every other PipeWire client, until something else eventually tears it down.

This path is hit every time a capture is renewed after CaptureEligibility::NeedsRestart - start_capture() gets called again for an object_id that already has an active stream, so add_stream()'s eviction branch runs on every restart, not just on genuinely new captures.

Verified live (this module has no existing test coverage - StreamRc requires a real, connected PipeWire core to construct, nothing here is mocked):

• Before the fix: launched a test instance, forced repeated link churn against a node (so it kept needing NeedsRestart), and watched pw-dump for "wiremix-capture"-named nodes climb and stay elevated well past what the instance's own capturing_objects said it was capturing.
• After the fix: same repeated-restart stress, pw-dump's count tracked the instance's actual active capture count exactly, and clean shutdown (Ctrl+C) always returned the graph to baseline with nothing orphaned.
• cargo test --release: 144/144 passing (no regressions; this fix doesn't touch anything under existing test coverage)
• cargo fmt --check / cargo clippy -- -D warnings / cargo doc (matching this repo's CI): all clean