Nice root-cause analysis and clean fix, @NF0T. The dual-subscription → 2× audio speed chain is well explained and the fix addresses it at two levels — good defense in depth.

What looks good

• Belt-and-suspenders design: registerDaxStream eviction prevents duplicates regardless of caller, while ensureDaxForTci avoids creating them in the first place. Either layer alone would fix the bug; both together make regressions harder.
• Borrow semantics: Tracking borrowed channels so releaseDaxForTci doesn't tear down DaxBridge-owned streams is the right approach. The m_tciDaxBorrowedChannels set is cleared alongside m_tciDaxStreamIds — no stale state.
• Thread safety: daxStreamIdForChannel correctly takes m_streamMutex, consistent with the existing locking discipline in PanadapterStream.
• Scope: Four files, all within the TCI/DAX stream path. No unrelated changes.
• Conventions: RAII mutex locking, proper Qt patterns, no QSettings usage.

One thing to consider (non-blocking)

Borrowed stream going stale: If DaxBridge tears down its DAX RX stream (e.g., user toggles DAX off in the UI) while TCI holds a borrowed reference, m_tciDaxStreamIds[ch] will point to a now-dead stream ID. Audio for that channel will silently stop — which is probably fine since the user explicitly killed DAX — but on a subsequent ensureDaxForTci call (e.g., a new TCI client connects), daxStreamIdForChannel will return 0, and TCI will correctly create a fresh stream. So the self-healing path exists. Just worth noting that there's a window where TCI thinks it has a stream but audio isn't flowing. A log message when daxAudioReady stops arriving for a borrowed channel could help operators debug, but that's a future enhancement, not a blocker.

Overall this is a well-targeted fix. Thanks for tracking down the duplicate-stream root cause — that's a subtle interaction between DaxBridge and TciServer that wasn't obvious from either side alone. 73!