feat: implement bt/2.4ghz fr800x driver

[damex]

Description

drivers/fr800x.{c,h}: shared core for the freqchip fr8003a uart chip.
state machine, opcode framing, queue, 6kro/nkro projection, chip init
sequence (HANDSHAKE + SLEEP_BLUETOOTH_ENABLE + SLEEP_DONGLE_ENABLE),
target switching (3 BT slots + dongle), battery query, charging-state
relay.

reconnect lifecycle: 2 s retry while DISCONNECTED re-issues target +
HANDSHAKE (timer reset by every target_change to avoid race); per-target
PAIRING-to-DISCONNECTED timeout and per-target HANDSHAKE link probe
registered by adapters via fr800x_target_set_pairing_timeout and
fr800x_target_set_probe_interval. On a dead link the chip emits 0x33
which fires the existing reconnect path.

boot order: boards must call fr800x_chip_init before any slot select
(typically before connection_host_changed_kb in keyboard_post_init_kb).
Without that order the chip's RF monitoring stays half-configured and
silent radio losses go undetected.

weak fr800x_receive_connection_cb and fr800x_receive_host_cb expose
chip state and host suspend/resume to boards.

drivers/bluetooth/fr800x.c and drivers/wireless/fr800x.c: thin adapters
routing each driver's send/profile/unpair/leds/is_connected to the
core. wireless adapter pushes dongle manufacturer/product/vid+pid
descriptors on every DONGLE select (chip's 2.4G stack needs them to
fully initialize RF monitoring) and registers 5 s pairing timeout +
5 s link probe for DONGLE. bluetooth adapter registers 30 s pairing
timeout for BT slots 1-3 (no probe; chip's BLE link supervision handles
loss). fr800x_init is idempotent so dual-enable links cleanly.

builddefs/common_features.mk: register fr800x in BLUETOOTH and
WIRELESS_2P4GHZ driver-type lists; both set FR800X_DRIVER_REQUIRED and
require UART_FRAME.

data/schemas/keyboard.jsonschema: add fr800x to both driver enums.
docs: features/wireless.md, drivers/wireless_2p4ghz.md, config_options.md,
and reference_info_json.md list fr800x as a driver option.

soc-side uart protocol reverse-engineered from traffic sniffed with a
miniware la104 on a freqchip fr8003a.

depends on the bluetooth multi-profile and 2.4ghz wireless api PRs to
land first.

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout (addition or update)
• Documentation

Issues Fixed or Closed by This PR

Checklist

• My code follows the code style of this project: C, Python
• I have read the PR Checklist document and have made the appropriate changes.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[damex]

also noticed that it needs reconnection mechanic. implemented it on disconnection. otherwise if keyboard drop connection for whatever reason (signal drop, dongle plugged out or whatever else) there is no way to get back unless you switch profiles.

it was like this:
2.4g -> drop connection-> no automatically working 2.4g
and one need to do this instead:
2.4g -> drop connection -> switch to bt or usb -> switch back to 2.4g

right now is much more user friendly:
2.4g -> drop -> reconnection attempt on 'disconnect' every 2 seconds (configurable) -> 2.4g works without user interaction

made changes, squashed and repushed those back.

[drashna]

A lot of this looks like it's using a separate path for bt and wireless. I'm not sure that's the correct path for this. Eg, it should be a unified framework that doesn't care which it is using.

[drashna]

new keycodes shouldn't be added to existing files. A new version should be added.

[damex]

The unpair keycode comes from #26203, not this pull request

Should the keycode go in its own pull request, or stay part of #26203?

Want to review all three related pull requests together (here), or separately?

[damex]

@drashna i added a new version with that keycode (next available is 0.0.9). done for both #26207 and #26203

[damex]

A lot of this looks like it's using a separate path for bt and wireless. I'm not sure that's the correct path for this. Eg, it should be a unified framework that doesn't care which it is using.

fr8003a is one chip
common state machine, queue, retry, parser, indicator, link probe, and pairing timeout all live in drivers/fr800x.c.
The bt/wireless split exists because QMK has two driver-type buckets (bluetooth_driver_t, wireless_2p4ghz_driver_t), not because the code is two paths

each transport file holds only its own protocol bytes plus the framework wrappers that forward to the common driver
no shared state crosses files

Want me to collapse both into a single drivers/fr800x.{c,h} or we're good with such split?