MOR-1410 child: make AF/RF keyboard adjustment usable on default macOS shortcuts

[morozsm]

Parent: MOR-1410 / Core #2318. Matching Linear child: https://linear.app/morozsm/issue/MOR-1632.

Problem

Exact candidate 8290e62 declares AF Ctrl+ArrowUp / Ctrl+ArrowDown and RF Ctrl+Shift+ArrowUp / Ctrl+Shift+ArrowDown in rigs/_keyboard-default.toml.

On standard macOS settings, Ctrl+ArrowUp is intercepted by Mission Control, blocking the required MOR-1410 desktop AF adjustment step. This finding requests no backend or radio change.

Required outcome

• Provide a discoverable macOS-safe AF and RF keyboard path under default system shortcuts, without triggering a system shortcut.
• Preserve appropriate non-macOS behavior. Do not choose a replacement chord without collision and UX evidence.
• Preserve keyboard suppression for INPUT, TEXTAREA, SELECT, and local extension keyboard scope; retain native Tab traversal and platform conventions.
• Prove exact AF/RF intent and declared up/down delta behavior, plus focus/input suppression.
• If existing g then a (Go to AF) is selected as the macOS path, disclose its next native adjustment in keyboard help/label; otherwise accurately disclose the selected path.
• Recheck IC-7300 desktop flow with PTT OFF, TUNE OFF, and audio OFF; no unintended backend write or radio mutation from the focus/system-shortcut path.

Candidate evidence and bounded scope

The keyboard map matches modifiers exactly and suppresses editable/local-extension scope. KeyboardHandler.svelte supplies ? help and reserves Tab. panel-commands.ts already routes declared AF/RF delta through existing intent handlers.

Implementation budget: at most 3 existing paths / 400 LOC. No backend, profile capability, CI-V, command serialization, StateStore, PTT/TUNE, audio, scope/waterfall, or transport change. Do not ask users to disable/reconfigure macOS shortcuts or add a model-specific branch.

Priority P1: not a radio-safety/protocol defect, but it blocks the standard-macOS operator path required by the MOR-1410 release gate. Reclassify P2 only if the existing focus path is proven discoverable and sufficient without a code change.

[morozsm]

Source correction: the candidate profile already declares both macOS-safe focus sequences: g then a (“Go to AF”) and g then r (“Go to RF”). Focused value controls support native Arrow adjustment and Shift fine adjustment. The implementation decision is therefore whether this existing route is reachable and discoverable enough under the acceptance criteria, not an assumption that RF lacks a focus route.