fix(rp2350): preserve dual-transport and ROM UF2 rejection diagnostics #1245

Context

FastLED/FastLED#3832 bring-up on an attached RP2350W reached a repeatable recovery state where fbuild's returned error loses the decisive transport diagnostic.

Exact target and host evidence:

• runtime before reset: COM17, 2E8A:F00F, serial 2DCB876B587EA334
• BOOTSEL after reset: healthy composite USB\VID_2E8A&PID_0003\E0C9125B0D9B
• MI_00: healthy USB mass storage, mounted as healthy RPI-RP2 on G:
• MI_01: healthy RP2 Boot (Interface 1) with WinUSB service
• topology: BOOTSEL is behind external hub USB\VID_0BDA&PID_5411\7&25f0bd90&1&3
• installed fbuild: 2.5.6; source comparison: current main at 5a42f4a0
• artifact: RP2350 family 0xE48BFF59, valid RP2350 errata absolute block 0xE48BFF57, 1,393,152 bytes

Reproduction:

fbuild deploy .build/pio/rp2350w -e rp2350w `
  -p 'UF2=G:\' --transport picotool --skip-build -v

The PICOBOOT interface is healthy and WinUSB-bound, so the picotool-primary path is eligible. The returned CLI error is only:

deploy failed: RP2040 BOOTSEL volume G:\ did not eject after NEW.UF2; deployment is unconfirmed

It omits the picotool probe/load failure that should be composed by rp2040_picotool::format_failure, and it does not run or surface picotool uf2 info after the ROM leaves the volume mounted. The daemon then attaches a typed recovery request for the stale phantom runtime CDC, which is useful but does not explain why both stock transports failed.

This is related to #1161 but narrower: #1161 tracks the underlying storage/flash-path investigation and watchdog cleanup. This issue tracks preserving and augmenting the transport evidence needed to diagnose that failure safely.

Proposal

1. Preserve the picotool-primary probe/load error when the mass-storage fallback also reaches an eject timeout.
2. When BOOTSEL remains reachable after a rejected/unconfirmed UF2 download, invoke the managed picotool's read-only uf2 info diagnostic under a bounded timeout and append any ROM-reported reason.
3. Keep typed Windows recovery guidance additive; it must not replace either transport's original error.
4. Do not invoke unmanaged picotool, raw serial, or a direct flasher.

Acceptance criteria

• A picotool-primary failure followed by a mass-storage eject timeout reports both failures in order.
• A bounded managed picotool uf2 info probe is attempted only while a BOOTSEL interface remains reachable and its output is included when available.
• Failure/timeout of the diagnostic itself cannot extend or replace the primary deploy error.
• Typed USB recovery guidance remains present and additive.
• Unit tests cover: both-transport composition, ROM diagnostic present, ROM diagnostic unavailable, and bounded timeout.
• Attached RP2350W evidence records the exact command, identity, and resulting actionable diagnostic.

Related issues

• investigate(rp2040): readable BOOTSEL volume stalls on first write; make watchdog cleanup handle-safe #1161 — underlying readable-BOOTSEL/flash-path investigation and watchdog cleanup
• investigate(rp2040): harden hub-path BOOTSEL mass-storage diagnostics #1081 — hub-path BOOTSEL diagnostics (closed)
• feat(rp2350w): complete pin-free AutoResearch and ESP32-C6 peer-network bring-up FastLED#3832 — RP2350W bring-up parent