Follow-up from #2222.

The deferred pan-status queue (m_pendingPanStatuses) holds display pan status that arrives without client_handle until ownership can be confirmed. Cleanup paths:

• ✅ Cleared on disconnect (added in [dax] [panadapter] Fix multi-client startup panadapter creation #2222 follow-up commit 3a908961)
• ✅ Cleared per-pan when display pan ... removed arrives
• ✅ Cleared per-pan when ownership is confirmed (entry consumed by ensureOwnedPanadapter)
• ⚠️ Cleared per-pan when client_handle arrives and shows the pan belongs to another client

Edge case not covered: if status keeps arriving for a non-owned pan that never emits removed (e.g., another client owns it indefinitely and the radio doesn't advertise client_handle on its first frame), the entry stays in the map forever. Each subsequent status frame with client_handle going to a non-owned pan does cleanup it, so this only matters when the radio never sends a client_handle-bearing frame for that pan.

Severity: low. In practice, every Multi-Flex client emits client_handle on its pans within a few hundred ms of pan creation, so the map self-cleans quickly. Worst case it leaks a few QMap<QString, QString> entries per long-running multi-radio session.

Suggested fix: add a TTL or a periodic sweep — drop pending entries older than ~30 s. Or migrate to a QMap<QString, QPair<qint64, QMap<QString, QString>>> with an entry-time and check on each insert.

Tagging for tracking; not urgent.