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

[zackees]

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.

[zackees]

Two-pass investigation complete; deferring this follow-up rather than making an unverified recovery change.

Pass 1 ? live behavior:

• Released/global/repo fbuild are all 2.5.18.
• fbuild port scan sees the exact RP2350W runtime record as COM18 / serial 2DCB876B587EA334 / health=phantom present=no selectable=no.
• Windows still reports the code-43 node at Port_#0014.Hub_#0001; the ESP32-C6 on COM9 is independently healthy.
• The successful PICOBOOT flash left no application CDC, Arduino-Pico Reset WinUSB, or ROM PICOBOOT endpoint that a non-admin process can address.
• A scoped retry fails closed; --admin correctly refuses to elevate from the non-interactive automation session.

Pass 2 ? implementation boundary:

• fix(rp): recover application USB without replug #1304 already contains the target-bound application Reset-interface path and exact/topology-bound PnP restart path.
• The remaining software option is the privileged Windows device-local restart. Windows does not permit a normal non-interactive process to manufacture UAC consent.
• Making that unattended requires an explicitly installed privileged broker/service (or equivalent pre-authorized mechanism), including authentication, exact-device authorization, lifecycle, upgrade, and threat-model work. It is not safe to improvise inside a deploy retry.
• Runtime proof is currently impossible because the board has no usable endpoint; it must first be physically replugged/BOOTSEL-recovered or restarted via an interactive elevated action.

Restart criteria:

1. Choose and threat-model the unattended Windows elevation/broker design, or explicitly scope acceptance to a pre-elevated fbuild session.
2. Restore the attached board once and capture the precise device/reset/PICOBOOT transition that produces code 43.
3. Add the typed state-machine regression and structured non-operational deploy result.
4. Prove exact-target safety and 100 consecutive deploy/runtime-CDC/RPC cycles, including injected post-flash CDC loss.

No unsafe hub/controller reset, raw picotool invocation, or ambiguous-device recovery was attempted.