CAT/TCI cross-band tunes bypass band-stack preselect — radio never restores per-band antenna/state

What

CAT (rigctl) and TCI frequency commands bypass the band-stack preselect that GUI tunes get. RigctlProtocol::cmdSetFreq (src/core/RigctlProtocol.cpp) and the TCI frequency handler (src/core/TciProtocol.cpp) call SliceModel::tuneAndRecenter() directly, which emits a raw slice tune. GUI direct-entry tunes instead funnel through MainWindow::applyTuneRequest with TuneIntent::CommandedTargetCenter, which calls preselectBandStackForTune and sends display pan set <pan> band=<key> before the tune.

The result: a cross-band frequency change from external software (WSJT-X, JS8Call, loggers via CAT/TCI/OmniRig) never triggers the radio's per-band band-stack recall — frequency moves, but the radio's saved per-band antenna, mode, filters, and pan state are not restored.

Why it matters

The most serious symptom is the transverter scenario from #3531: a WSJT-X band change to 144 MHz moves the slice onto an XVTR band without the radio recalling the saved XVTR antenna port, so the radio can key into the wrong port — an equipment-damage hazard for transverters and amplifiers.

This is the root-cause fix identified in the #3531 triage. The client-side antenna-mapping alternative was rejected (PR #3540) because band changes are radio-authoritative in AetherSDR — the Flex band stack owns per-band antenna/mode/filter/pan restore (maintainer note in MainWindow_Wiring.cpp, history in #1876/#1887). The fix here keeps that policy: make external band changes take the same radio-authoritative path as GUI band changes, and let the radio restore its own state.

Proposed fix

Route CAT/TCI cross-band commanded tunes through the same funnel as GUI direct entry:

• Have RigctlProtocol / TciProtocol emit a tune-request that MainWindow services via applyTuneRequest(slice, mhz, TuneIntent::CommandedTargetCenter, "rigctl"/"tci") instead of calling tuneAndRecenter() directly.
• Mind the worker→GUI thread hop; the existing QMetaObject::invokeMethod pattern in those protocol classes applies.
• Same-band retunes should remain a plain slice tune — the preselect only matters when the tune crosses into a different band-stack key (including X<n> XVTR keys via XvtrPolicy::resolveBandStackKey / transverterIndexForFrequency).

This also fixes related asymmetries for free: SWR-sweep clearing, m_bandSettings current-band tracking, and the >54 MHz no-XVTR guard that GUI tunes get but CAT/TCI tunes skip.

Out of scope

• Any client-side antenna mapping or override — rejected in PR #3540, deferred to #2035 (per-band antenna matrix + TX interlock).
• The first-ever visit to a transverter band (no band-stack antenna record yet; radio may default to ANT1). Routing can't solve that; it belongs to #2035.

Verification

• WSJT-X via CAT and via TCI: cross-band change onto an XVTR band restores the saved XVTR antenna; same-band retunes (FT8 sub-band hops) don't churn the band stack.
• Cross-band change between native bands restores per-band mode/filter/antenna identically to clicking the band button.
• No regression in rapid retune streams (WSJT-X tune-up, contest loggers).

Refs: #3531 (closed, original report), PR #3540 (closed, rejected client-side approach), #2035 (override design), #1876/#1887 (radio-authoritative history).

Start with RigctlProtocol::cmdSetFreq in src/core/RigctlProtocol.cpp, the TCI frequency handler in src/core/TciProtocol.cpp, and MainWindow::applyTuneRequest. Trace the existing QMetaObject::invokeMethod worker-to-GUI path and preselectBandStackForTune, including XvtrPolicy band-key handling. Done means CAT and TCI cross-band tunes restore the saved band state while same-band retunes remain plain tunes, matching the listed WSJT-X and native-band verification cases.