Add an nRF52 2.4GHz bridge that mirrors the ESP-NOW one

[ViezeVingertjes]

Bridging already works on nRF over RS232, but the wireless transport was ESP32-only. This adds the nRF equivalent using Nordic's 1 Mbit proprietary mode: one fixed address every bridge shares, no pairing or acknowledgement, which is what ESP-NOW's broadcast peer amounts to.

The two radios are not compatible on air. An nRF bridge only pairs with another nRF bridge.

Same behaviour as ESP-NOW

Same frame format (magic 0xC03E, Fletcher-16, XOR with bridge_secret), same duplicate suppression, same bridge.delay / bridge.source / bridge.enabled handling. bridge.channel keeps its Wi-Fi 1-14 numbering and maps onto the same centre frequencies, so a channel means the same thing on either platform and the persisted prefs are unchanged. An out-of-range channel is refused rather than corrected, matching ESP-NOW, where esp_wifi_set_channel() rejects it and the bridge does not start.

get bridge.type returns nrf, and the advert features byte uses 0x05. Clients decoding that byte need to learn the new value.

Interrupt context

RADIO reports frames in an interrupt rather than on a driver task, and the packet pool, inbound queue and seen-packet table have no locking. The handler copies the frame into a small ring buffer and loop() turns those into mesh packets on the main task. This is the one structural difference from ESPNowBridge, which can do that work in its callback.

SoftDevice

The nRF52 has one RADIO and the SoftDevice owns it whenever BLE is up, so the bridge refuses to start while the SoftDevice is enabled, and start ota now stops the bridge before bringing it up. That guard helps ESP32 too, where OTA wants the Wi-Fi interface ESP-NOW is holding.

Testing

Unit tests cover the channel mapping. Builds clean for RAK_4631_repeater_bridge_nrf (15.1% RAM, 53.3% flash), and the RS232 and ESP-NOW targets still build.