feat(rp2350w): 添加 btstack BLE GATT 传输

上下文 FastLED #3832 需要一个 RP2350W BLE 审核。选用的 Arduino-Pico 4.5.3 核心包含 BluetoothHCI、btstack 和 CYW43 蓝牙锁定钩子。然而，src/fl/net/ble.h 仅为 ESP32 NimBLE 定义了 FL_BLE_AVAILABLE，src/fl/net/ble.cpp.hpp 在 RP2350W 上返回代理，并且只有 ESP32 BLE 单元构建提供了传输。核心示例证明了扫描/客户端导向的蓝牙，而 BluetoothHCI.cpp 直接使用 att_server_init，因此 FastLED GATT 服务器是可实现的，但目前尚未集成。 ## 建议 添加一个由 RP2350W btstack 支持的 fl::net::ble GATT 传输，该传输实现了现有的 UUID 和远程回调协议。添加一个平台分派/构建片段，而不是更改公共 API。通过 fl::atomic 或适当的临界区保持回调/主循环交接的无竞争性，通过 fl::Singleton 保持所有持久的 FastLED 状态，并在实际的 RP2350W Arduino-Pico 头文件和 CYW43 支持上关闭 FL_BLE_AVAILABLE。 ## 接受标准 - 添加一个重点 RED 编译/单元重现，显示 RP2350W 目前选择了 BLE 代理，然后使其变为绿色，使用真实的 RP 传输。 - 保留 ESP32 NimBLE 行为和不受支持的平台代理。 - 使用测试覆盖 create/destroy、广告、RX 写入 JSON-RPC 请求回调、TX 通知、断开连接和有界队列满的行为。 - 在 fl::Singleton 外部没有可变的静态 FastLED 状态，也没有裸露的跨上下文状态。 - bash lint --cpp --strict 加上针对 rp2350w 和 esp32c6 的目标构建通过。 - 一旦 COM17 正常可用和可选择，bash autoresearch rp2350w --ble --upload-port COM17 --timeout 120s 记录了实际的 GATT 探索/ping 结果。没有一次性草图或直接串行/闪存路径。 ## 开放问题 核心公共 BluetoothHCI 示例强调扫描/客户端使用，因此第一个实现必须验证其直接 btstack GATT 服务器生命周期，并在连接的 Pico 2 W 上文档化支持的 MTU/通知行为。 ## 相关问题 父问题 #3832。