feat: Ble_manager - add wireless.bluetooth.channel Focus command (host-side BT channel switching)

[Cylindrix]

Motivation

Multi-host users (keyboard paired to a PC and a laptop, KVM-style setups) currently have no way to switch the active Bluetooth channel from the host. The only path is the physical sequence: Bluetooth pairing key, then a number key. That sequence cannot be automated:

• The Focus API exposes no Bluetooth commands (the wireless.bluetooth.* handlers in Ble_manager.cpp are commented out).
• Triggering a stored macro via macros.trigger gets as far as opening pairing mode, but the channel keys are matched by physical coordinate (coord.row/coord.col) in kbdif_key_event_process, so a macro-played digit is ignored. (Verified on a Raise 2, firmware v1.4.1.)

This PR adds one Focus command so hosts and Bazecor can do it directly:

wireless.bluetooth.channel       -> returns the active channel (1-5, matching the keycaps)
wireless.bluetooth.channel 2     -> switches to channel 2

Implementation

• The channel-switch procedure that ran inline in the number-key handler is extracted unchanged into BleManager::change_channel(uint8_t index_channel); the key handler now calls it. No behavioral change to the existing key path.
• kbdif_command_event_cb (previously a commented-out sketch) now delegates to a new kbdif_command_event_process instance method, mirroring how kbdif_key_event_cb delegates, and implements the command following the pattern of RadioManager::kbdif_command_event_cb (wireless.rf.*).
• Writes are guarded: channel must be 1..BLE_CONNECTIONS_COUNT, and the switch only runs when ble_innited() and FirmwareVersion::keyboard_is_wireless(). Switching to the already-active channel is a no-op.
• 1-based channel numbers on the wire to match the keycaps and LED effect the user sees.

One expected quirk, noted in a comment: when the requesting host is connected over Bluetooth on the channel being switched away from, the link drops mid-procedure, so that host may never receive the Focus reply. The switch itself completes.

Testing

I could not compile this: the build depends on the private kaleidoscope_adapter submodule (see #33), so external contributors cannot build the firmware. The change is a mechanical extraction plus a handler modeled closely on the working wireless.rf.* handler, but it has not been flashed or run. I have a Raise 2 (ANSI, wireless) and I am happy to test a build or a beta release that includes this and report back.

🤖 Generated with Claude Code