Problem

The radio-side dax_rx stream map lives in a single PanadapterStream (one per radio), but three independent consumers each hand-roll their own ownership bookkeeping on top of it and coordinate by peeking at each other's state:

PanadapterStream itself only exposes registerDaxStream() / unregisterDaxStream() / daxStreamIdForChannel() — no notion of who holds a channel or how many holders there are. So each consumer reimplements "is anyone else using this channel?" by reaching into the others:

• TCI borrows a stream the bridge created and refuses to remove borrowed channels in releaseDaxForTci() (src/core/TciServer.cpp), explicitly to avoid silencing other consumers.
• The bridge now consults TciServer::ownsDaxChannel() and compares against m_radeDaxStreamId before removing a stream (added in DAX virtual audio: only slice 0 gets audio client on Linux PipeWire headless (RPi 5, Ubuntu 24.04, FLEX-8600) #2895).

This works but is fragile and O(consumers²): every new consumer has to learn about every existing one, and any missed cross-check silently tears out a stream another consumer needs (the #3270 failure mode, which #2895/#3282 patched from two directions).

Proposed direction

Replace the per-consumer ownership maps with centralized refcounting in PanadapterStream:

// rough shape
quint32 acquireDaxChannel(int channel, DaxConsumer who);  // creates stream if refcount 0→1, else reuses
void    releaseDaxChannel(int channel, DaxConsumer who);  // sends `stream remove` only when refcount 1→0

• PanadapterStream owns the channel→(streamId, refcount, holders) table and is the single place that emits stream create / stream remove.
• Consumers call acquire/release and stop tracking stream IDs and each other entirely.
• Removal happens only when the last holder releases — no consumer can stomp another.
• Keeps the slice set <id> dax=<ch> client-registration re-assert (Broken TCI audio tested on Win11 #1439) as a separate concern.

Context / predecessors (contained fixes already landed/in-flight)

• No TCI audio going to WSJTX #3270 — No TCI audio to WSJT-X (the core late-arrival failure mode)
• fix(tci): re-arm DAX RX when radio or slice arrives after audio_start (#3270). Principle I. #3282 — re-arm DAX RX in TciServer on reconnect/sliceAdded
• DAX virtual audio: only slice 0 gets audio client on Linux PipeWire headless (RPi 5, Ubuntu 24.04, FLEX-8600) #2895 — re-arm DAX RX in the bridge on per-slice daxChannelChanged + reciprocal ownership guard against TCI/RADE
• Design: TCI audio should use independent DAX path #1331 / Broken TCI audio tested on Win11 #1439 — original TCI DAX client-registration workarounds

These are the contained, per-path predecessors; this issue tracks the structural consolidation we deferred to a later release.

Notes

• Architecture change (new ownership model + signal/ownership routing) → maintainer design call before implementation.
• Should preserve: slice 0 RX flow, the Broken TCI audio tested on Win11 #1439 re-assert, borrowed-stream semantics (no double stream create → double-speed audio), and clean teardown on disconnect/stopDax/releaseDaxForTci.