test(rp2350): complete RP2350(W) loopback driver and subsystem HIL

Context

Finish the RP2350 and RP2350W hardware bring-up on the currently available Pico 2 W fixture, using the existing AutoResearch/fbuild path and the board's soldered two-pin feedback bridge.

The 2026-08-18 inventory shows:

• historical RP2350W CDC identity: COM17, 2E8A:F00F, serial 2DCB876B587EA334; Windows currently reports this saved record as health=phantom selectable=no, so current physical enumeration still must be established;
• healthy Espressif peer: COM9, 303A:1001, serial 8C:BF:EA:CF:87:B4; the USB PID is shared, so firmware-level chip detection must confirm ESP32-C6 before peer tests;
• prior bench notes on #3832 and #3864 record the soldered bridge as GPIO0 (TX) -> GPIO1 (RX), but this run must confirm that mapping through live findConnectedPins/GPIO evidence before relying on it.

Most source-side RP2350W foundation work has landed: board/deploy support, PIO0/1/2 channel selection, serial RPC, watchdog recovery, CYW43 networking, peer HTTP/JSON-RPC, OTA staging, and btstack BLE transport. What remains is a single evidence-backed closeout of every driver and subsystem reachable with the attached hardware.

Proposal

1. Re-establish the RP2350W through fbuild port scan and the normal RP BOOTSEL/CDC deployment path. Do not pin a stale COM17 record; omit --upload-port unless multiple RP boards are actually present, or use UF2=<volume> if the board is deliberately in BOOTSEL.
2. Run GPIO-only AutoResearch with pin discovery and record the physically observed bridge. The historical GPIO0 -> GPIO1 note is a hypothesis until the current firmware reports it.
3. Validate both rp2350 and rp2350w profiles on the Pico 2 W so common silicon support and W-specific transports are separately covered.
4. Exercise every RP driver reachable with the discovered bridge through the public FastLED/Channels API where available:
   • PIO0, PIO1, and RP2350-only PIO2 clockless TX with PIO RX byte/edge evidence;
   • PIO0 + PIO1 simultaneous resource/concurrency behavior;
   • UART clockless output on any hardware UART route compatible with the discovered bridge (GPIO0 -> GPIO1 is UART0 TX/RX);
   • AUTO and BIT_BANG fallback behavior through the user-facing API;
   • arbitrary-pin PIO SPI if the harness supports capture on the bridge;
   • fixed-function SPI0/SPI1 and APA102/SK9822 only when the present wiring can form the required MOSI -> MISO route; otherwise record the exact pin incompatibility as not reachable in this fixture, not as a pass.
5. Complete the RP2350W-only gates already prepared by #3832: RPC smoke, IEEE-754, SIMD, watchdog/reconnect, RP dual-core concurrency, Wave2D, ESP32-C6 peer networking, BLE GATT, and peer OTA.
6. Preserve exact command/output evidence on this issue and update parent #3832 with the final matrix.

Acceptance criteria

• A focused RED -> GREEN repro is recorded for every source/harness gap discovered while enabling RP2350 HIL (including any RP2040-only CLI restriction that must be generalized).
• fbuild port scan records the live RP board identity/port and the healthy peer identity; firmware-level detection confirms the peer chip before ESP32-C6 use.
• AutoResearch live pin discovery reports the soldered pair and testGpioConnection proves LOW/HIGH feedback; no pin mapping is accepted from historical notes alone.
• The rp2350 and rp2350w build/deploy/serial RPC paths both pass on the attached Pico 2 W.
• PIO0, PIO1, and PIO2 each produce decisive byte/edge loopback evidence through the public driver path.
• PIO0 + PIO1 simultaneous execution passes without resource collision, stale state machine, or DMA ownership leak.
• Every UART, SPI, AUTO, BIT_BANG, and PIO-SPI path physically reachable with the discovered bridge is tested; every unreachable path is listed with the exact wiring/peripheral constraint.
• RP2350W RPC smoke, IEEE-754, SIMD, watchdog/reconnect, concurrency, and Wave2D gates pass or produce a concrete tracked implementation gap.
• RP2350W <-> ESP32-C6 peer HTTP/JSON-RPC, >=4 KiB payloads in both directions, ten reconnect cycles, BLE GATT, and OTA recovery pass when the peer is firmware-confirmed as C6.
• Closeout records the exact commands, commits, wiring, ports, VID:PIDs/serials, and decisive REMOTE:/RESULT: lines.
• No raw flasher, raw pyserial path, one-off sketch, host-WiFi switch, guessed register map, or unsupported-peripheral shim is introduced.
• Relevant lint, focused tests, RP2350/RP2350W builds, code review, PR delivery, and post-merge live rerun are complete.

Decisions

• Treat the attached Pico 2 W as both the RP2350 common-silicon DUT and the RP2350W transport DUT; this covers both profiles without pretending a second board exists.
• Keep this issue focused on live driver/subsystem completion; #3832 remains the parent for the broader pin-free/network work.
• Treat prior GPIO0 -> GPIO1 documentation as a lead only; live discovery is the authority for the current physical bridge.
• Count a driver as complete only with live feedback evidence through the normal API. Compile-only or raw peripheral evidence is supporting evidence, not closeout.
• Mark physically unreachable fixed-pin routes explicitly rather than changing soldered wiring or inferring success.

Open questions

• Which present USB node/BOOTSEL volume belongs to the Pico 2 W after the user-reported reattachment? The saved COM17 record is not currently present, so this must be resolved from a fresh scan/deploy result.
• Whether the current two-pin bridge permits any fixed-function SPI route depends on the live-discovered pins; the historical GPIO0/GPIO1 pair supports UART0 and arbitrary-pin PIO tests but not the canonical SPI0/1 MOSI -> MISO pairs.

Related issues

• #3832 — parent RP2350W pin-free, network, and hardware bring-up
• #3864 — prior final-HIL handoff, including GPIO0 -> GPIO1 wiring history and RP BOOTSEL guidance
• #3861 — RP2350W btstack BLE GATT transport and pending live proof
• #3647 — RP2040 RX-first PIO/UART/SPI driver bring-up precedent
• #3648 — RP2040 transport/channel-driver closeout precedent
• #3631 — RP2040 GPIO/PIO/LED loopback hardware precedent
• #1673 — original Pico 2/RP2350 support
• FastLED/fbuild#1282 — RP-series attachment/phantom-port handoff guidance