…ple XI.

The deferred `m_pendingPanStatuses` queue in `RadioModel` holds
`display pan` status that arrives without a `client_handle` so
ownership can be confirmed later. Existing cleanup paths cover the
common cases (disconnect, `removed`, ownership confirmed, non-owned
with `client_handle`), but a pan that another client owns and that
the radio never re-emits with `client_handle` (and never marks
`removed`) leaks an entry indefinitely.

Pair each map value with a `QDateTime::currentSecsSinceEpoch()`
timestamp captured at insert, and sweep entries older than 30 s
each time we insert. Per maintainer note on the issue: dropping a
stale pending entry is never observably wrong because consumption
only happens on ownership confirm — exactly the missing signal that
would otherwise free the entry. The map is small in practice
(typically <10 entries), so an O(N) sweep-on-insert is cheaper than
a periodic-timer alternative.

Three call sites adjusted for the new pair type: the `Defer` branch
of the pan-status handler (insert + sweep), the consumer in
`ensureOwnedPanadapter` (`pending.second`), and the existing
`.clear()`/`.remove()` paths need no change.

Blast radius: risk_score=0.476, 17 high-risk callers (top:
MainWindow::MainWindow, MainWindow::wirePanadapter,
MainWindow::buildMenuBar) — driven by the RadioModel.h include
fan-out. The field is private and its type change is contained to
three sites inside RadioModel.cpp; no public API, signal, or slot
shape changes, so the high-risk callers are not behaviorally
affected.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>