feat(rp2350w): add btstack BLE GATT transport

Context FastLED #3832 requires an RP2350W BLE audit. The selected Arduino-Pico 4.5.3 core ships BluetoothHCI, btstack, and CYW43 Bluetooth locking hooks. However, src/fl/net/ble.h defines FL_BLE_AVAILABLE only for ESP32 NimBLE, src/fl/net/ble.cpp.hpp returns stubs on RP2350W, and only the ESP32 BLE unity build supplies a transport. The core examples prove scanner/client-oriented BLE, while BluetoothHCI.cpp directly uses att_server_init, so a FastLED GATT server is implementable but not currently integrated. ## Proposal Add an RP2350W btstack-backed fl::net::ble GATT transport that implements the existing UUID and Remote callback contract. Add a platform dispatch/build fragment rather than changing the public API. Keep callback/main-loop handoff race-free with fl::atomic or an appropriate critical section, own all persistent FastLED state through fl::Singleton, and gate FL_BLE_AVAILABLE on the actual RP2350W Arduino-Pico headers and CYW43 support. ## Acceptance criteria - Add a focused RED compile/unit repro showing RP2350W currently selects the BLE stub, then make it green with the real RP transport. - Preserve ESP32 NimBLE behavior and unsupported-platform stubs. - Cover create/destroy, advertising, RX write to JSON-RPC request callback, TX notification, disconnect, and bounded queue-full behavior with tests. - No mutable static FastLED state outside fl::Singleton and no bare volatile cross-context state. - bash lint --cpp --strict plus target builds for rp2350w and esp32c6 pass. - Once COM17 is healthy/selectable, bash autoresearch rp2350w --ble --upload-port COM17 --timeout 120s records the actual GATT discovery/ping result. No one-off sketch or direct serial/flasher path. ## Open questions The core public BluetoothHCI examples emphasize scan/client use, so the first implementation must verify its direct btstack GATT-server lifecycle on the attached Pico 2 W and document the supported MTU/notification behavior. ## Related issues Parent #3832.