Follow-up from PR #3921 (merged as 34e3f3a).

That PR routed tuneToNet() through the canonical applyTuneRequest(..., TuneIntent::AbsoluteJump, "net-tune") path — the right call, and it fixes the #3918 cross-band VFO-display bug.

Minor behavior loss: the old bespoke net-tune path resolved the band-stack key via XvtrPolicy::resolveBandStackKey() and, when the target band was a transverter band the radio doesn't have configured, showed:

Can't tune <net> — <band> isn't available on this radio.

applyTuneRequest only runs band-stack preselect for TuneIntent::CommandedTargetCenter, not AbsoluteJump, so the net-tune path no longer performs that support check or surfaces the message. A net scheduled on an unconfigured XVTR band now just issues slice tune <freq> + recenter with no feedback.

This matches the DX-cluster spot path (also AbsoluteJump, also unguarded), so it's consistent and low-severity (XVTR-only) — but the actionable user message is gone.

Options:

• Pre-check XvtrPolicy::resolveBandStackKey() in tuneToNet() before calling applyTuneRequest, and show the existing "not available" message on !isSupported(); or
• Push the unsupported-band feedback down into the canonical tune policy so DX spots / typed VFO entry / net-tune all get consistent feedback (the deeper fix).

Edge case, not urgent.

🤖 Generated with Claude Code