feat(slice): add cycle_tx_slice shortcut action for FlexKnob/MIDI/keyboard

[chibondking]

Registers a new ShortcutManager action "cycle_tx_slice" in the Slice category with no default key binding. On each invocation the action advances the TX-designated slice one position forward through the currently-open owned-slice list (wrapping from last back to first).

--- How it works ---

SliceModel::setTxSlice(true) sends "slice set N tx=1" to the radio. The FLEX firmware handles exclusive TX assignment server-side: marking slice N as TX causes the radio to clear tx=0 on every other slice and broadcast the updated state to all connected clients. No client-side cleanup of the old TX slice is required.

The action is a no-op when only one slice is open (nothing to cycle to).

--- Intended use cases ---

• FlexKnob (FlexControl) programmable button — bind via the FlexControl binding dialog. Common workflow: operator running two slices (e.g. DIGU on 40 m for FT8 + SSB on 20 m for phone) and wants a single physical button to hand off TX between them without reaching for the mouse.

• MIDI controller — bind via the MIDI binding dialog. Same operator workflow; foot-switch or panel button.

• Keyboard — optionally assign a key in ShortcutDialog for keyboard- centric operators.

--- Design notes ---

Cycles in owned-slice-list order (the order slices were created / the order RadioModel::slices() returns them), which is deterministic and predictable. With two slices this is effectively a toggle. With three or more it advances A→B→C→A. Split mode is not blocked; calling setTxSlice on either split leg is valid protocol.

@AetherClaude any worries for the larger slice selection radios like the 6700?

[aethersdr-agent]

Looks good. Mirrors the existing next_slice/prev_slice/split_toggle shortcut pattern at src/gui/MainWindow.cpp:12480-12516 (no default key, single-slice guard, modular cycle, value-typed slices()). Relying on the radio's exclusive-TX echo to clear the old slice's tx=1 is consistent with how the rest of the codebase treats slice TX state.

On the 6700 question — a flat forward cycle through up to 8 owned slices is fine functionally, but a couple of small ergonomic notes for future iteration (not blocking this PR):

• With many slices, a single-direction cycle can be tedious. A symmetric cycle_tx_slice_prev would let operators bounce off the end. Cheap follow-up.
• The action cycles through every owned slice regardless of which panadapter it lives on, which is the right default for the FT8+SSB workflow you described. On a 6700 with 8 slices spread across 4 panadapters, an operator who explicitly wants "next TX slice on this pan" would have to scope it differently — worth keeping in mind if someone files a follow-up.

Neither is needed for this change. Thanks @chibondking.