meta(rp2040): switch deploy to PICOBOOT-primary transport (from #1161 mass-storage write-stall investigation)

[zackees]

Summary

Meta issue for the RP2040 deploy transport strategy change proposed in #1161 (analysis: #1161 (comment)).

fbuild's current primary RP2040 transport is the Windows mass-storage path — 1200-baud touch, wait for the RPI-RP2 volume, write NEW.UF2 through the filesystem/storage stack (crates/fbuild-deploy/src/rp2040.rs:1377-1448 at 16bb9ffa). Picotool/PICOBOOT is reached only as a fallback. The mass-storage path is exactly the surface implicated in the #1161 reproduction (write stalls, Disk 51/153 events).

The ecosystem comparison shows the direct PICOBOOT route is the proven default elsewhere:

Toolchain	Default transport	Notes
PlatformIO (platform-raspberrypi)	picotool via rp2040load (direct PICOBOOT)	1200-baud touch gated on board config
Arduino rp2040tools	picotool info → load → reboot
Arduino-pico core	UF2 volume copy (default), picotool load -f -x as first-class option
fbuild today	NEW.UF2 volume copy	picotool fallback lacks -f, no probe, 30s hard timeout

Sub-issues

• feat(rp2040): make PICOBOOT/picotool a first-class transport and the primary automatic deploy path #1162 — feat(rp2040): make PICOBOOT/picotool a first-class transport and the primary automatic deploy path
• feat(rp2040,windows): preflight PICOBOOT WinUSB driver binding and classify code-28 failures #1163 — feat(rp2040,windows): preflight PICOBOOT WinUSB driver binding and classify code-28 failures
• fix(rp2040): watchdog-abandoned UF2 write worker leaks the NEW.UF2 handle inside the daemon #1164 — fix(rp2040): watchdog-abandoned UF2 write worker leaks the NEW.UF2 handle inside the daemon
• test(rp2040): controlled PICOBOOT-only hardware validation with the #1161 pinned artifact #1165 — test(rp2040): controlled PICOBOOT-only hardware validation with the investigate(rp2040): readable BOOTSEL volume stalls on first write; make watchdog cleanup handle-safe #1161 pinned artifact

Suggested order

1. fix(rp2040): watchdog-abandoned UF2 write worker leaks the NEW.UF2 handle inside the daemon #1164 (watchdog handle leak) — independent correctness fix; stands regardless of the transport flip because mass-storage remains the fallback.
2. feat(rp2040,windows): preflight PICOBOOT WinUSB driver binding and classify code-28 failures #1163 (Windows driver preflight) — prerequisite for making PICOBOOT the default on Windows; the investigate(rp2040): readable BOOTSEL volume stalls on first write; make watchdog cleanup handle-safe #1161 host currently shows problem code 28 on MI_01.
3. feat(rp2040): make PICOBOOT/picotool a first-class transport and the primary automatic deploy path #1162 (transport flip) — the main change; mostly transport ordering, -f, picotool info probe, and error classification, since fbuild_packages::toolchain::Rp2040Picotool already exists.
4. test(rp2040): controlled PICOBOOT-only hardware validation with the #1161 pinned artifact #1165 (hardware validation) — gated on the bricked board re-enumerating (physical BOOTSEL/replug); validates the flip against the pinned artifact and cleanly isolates the investigate(rp2040): readable BOOTSEL volume stalls on first write; make watchdog cleanup handle-safe #1161 failure to the mass-storage path.

Exit criteria

• Default fbuild deploy on RP2040 loads over PICOBOOT without opening the RPI-RP2 volume; --transport uf2 restores the mass-storage path.
• Missing WinUSB binding fails fast with actionable guidance.
• A watchdog-timed-out write can no longer poison subsequent attempts.
• test(rp2040): controlled PICOBOOT-only hardware validation with the #1161 pinned artifact #1165's controlled run recorded on investigate(rp2040): readable BOOTSEL volume stalls on first write; make watchdog cleanup handle-safe #1161 with the pinned artifact.

Closes out the fbuild-side direction from #1161; that issue stays open for the host/device reproduction itself.

[zackees]

Additional host observation: UF2 volume bypass\n\nA separate investigator was able to get past the NEW.UF2 non-writability by dismounting the BOOTSEL volume and writing directly to its FAT filesystem rather than through the normal mounted-volume path.\n\nThis is useful evidence that the failing surface can be the Windows mounted mass-storage/filesystem stack, not necessarily UF2 parsing or RP2040 flash programming. It reinforces the PICOBOOT-primary direction: direct picotool avoids that storage stack entirely.\n\nThis is an investigation note only, not a deployment recommendation: fbuild should not add a raw-FAT workaround. The supported paths remain PICOBOOT/picotool as primary and the normal UF2 volume route as explicit fallback.