fix(rp): recover post-PICOBOOT code-43 CDC loss without replug #1331

Context

The attached RP2350W has reproduced the exact no-replug failure after #1304 merged and fbuild 2.5.18 was installed. This is a regression/follow-up to #1303, whose PR #1304 previously passed 50/50 deploy/RPC cycles on this same board and USB port.

Latest reproduction:

host: Windows
fbuild: 2.5.18
board/environment: rp2350w
runtime serial: 2DCB876B587EA334
prior runtime endpoint: COM18, 2E8A:F00F
physical location: Port_#0014.Hub_#0001 (direct root USB port)
command: bash autoresearch rp2350w --net-peer --upload-port COM18 --peer-environment esp32c6 --peer-upload-port COM9 --timeout 120s --skip-lint --quiet

The RP build and PICOBOOT flash completed, but application CDC never returned:

deploy succeeded (full flash); FBUILD_DEPLOY_PORT=; firmware deployed to RP2040 via PICOBOOT (managed picotool) (H:\); the firmware was flashed and accepted, but no healthy, openable runtime CDC port reappeared within 30s (elapsed 30009ms; prior port COM18; requested serial 2DCB876B587EA334; catalogue candidates: COM18 (serial 2DCB876B587EA334; health phantom; instance USB\VID_2E8A&PID_F00F&MI_00\8&20C14328&0&0000; parent USB\VID_2E8A&PID_F00F\2DCB876B587EA334))

A fresh fbuild port scan still reports COM18 as health=phantom present=no selectable=no, while Windows reports an unidentified USB problem-code-43 node at the same direct-root-port location. The unrelated ESP32-C6 remains healthy on COM9, so this is target-local rather than a complete host USB loss.

A direct sanctioned retry:

uv run fbuild .build/pio/rp2350w deploy -e rp2350w -p COM18

fails closed on the stale node and suggests --admin. Adding --admin from the non-interactive automation session reports that scoped PnP recovery needs an interactive Windows session and does not elevate. The board therefore remains inaccessible until physical replug/BOOTSEL or an interactive UAC recovery, preventing unattended HIL.

What remains after #1304

#1304 covers healthy application reset-interface recovery and exact/topology-bound Windows device restart, but this observed sequence leaves neither a healthy runtime CDC endpoint nor an automation-usable recovery path after a successful PICOBOOT flash. The deploy result is success even though the target is not operational and the only proposed recovery cannot execute in an unattended session.

Acceptance criteria

• Add a focused failing state-machine regression for: exact RP target -> PICOBOOT flash accepted -> no runtime CDC -> exact prior node phantom + uniquely correlated code-43 node.
• Preserve the exact board serial and physical topology across the PICOBOOT/application transition.
• Automatically attempt every safe, non-admin exact-target reset/re-enumeration layer before returning.
• Define and test an unattended Windows recovery mechanism for the uniquely correlated device-local restart, or return a typed non-success/blocked result that automation cannot mistake for an operational deployment.
• Never reset a hub/controller or an ambiguous/unrelated device.
• Keep successful firmware transfer distinct from successful operational deployment in both structured response and CLI exit behavior.
• On RP2350W serial 2DCB876B587EA334, run at least 100 consecutive build/deploy/runtime-CDC/RPC cycles on the same USB port, including injected post-flash CDC loss, with zero replug/BOOTSEL actions.
• Record whether the fault is device firmware, host PnP state, cable/power continuity, or controller behavior; do not claim recovery for physically absent hardware.

Decisions

• Treat this as a follow-up rather than reopening fix(rp): recover RP2350W deployment without USB replug #1303 because the merged recovery ladder is real and passed its original fault injections; this is a newly reproduced post-flash state.
• Keep implementation in fbuild. FastLED must continue using fbuild deploy and must not invoke picotool or PnP tooling directly.
• A successful flash with no operational endpoint is not sufficient for unattended deployment success.

Related: #1303, PR #1304, FastLED/FastLED#3832, FastLED/FastLED#3908, FastLED/FastLED#3953.