feat(deploy): CH32V wlink deployer - primary flashing strategy (WCH-LinkE, all 9 series)

[zackees]

Severity: HIGH — fbuild has no CH32V deployer. This issue is the researched replacement for the #1105 "Phase 2" outline: implement wlink as the primary CH32V flashing strategy.

Strategy decision (from the 2026-07-21 deployment-strategy audit)

The audit question was: is one strategy enough, and which one? Answer, backed by WCH datasheets and tool-repo research:

• wlink + a WCH-LinkE probe covers all 9 CH32V series fbuild builds (V003, V006, V103, V203, V208, V303, V307, X035, L103). It is Rust (MIT/Apache-2.0), actively maintained (v0.1.2, 2026-05-01), ships pinned per-OS release assets — exactly fbuild's pinned-external-flasher model (probe_rs.rs).
• No probe-free strategy covers everything: CH32V003/V006 have no USB peripheral and their UART bootloader cannot be entered on a blank chip (software-only entry, no BOOT pin) — a WCH-LinkE probe is mandatory for them regardless. USB-ISP (wchisp) covers only the other 7 series → tracked as a separate fallback-deployer issue.
• Do NOT adopt PlatformIO's default (wch-link = WCH's OpenOCD fork): the fork's source is email-request-only with no license file — unshippable. Support it at most as a user-supplied executable.
• probe-rs (already pinned in fbuild for ARM) has a native WCH-Link driver and released CH32V0/V2/V3 flash algorithms in v0.31.0, but V103/X035/L103/V006 targets are master-only — a fast-follow option, not the primary.
• minichlink remains the manual-fallback mentioned in the current error message; no release binaries of its own.

Implementation outline (per #1102's Phase-2 sketch, updated)

1. New module crates/fbuild-deploy/src/ch32v.rs (module, NOT a new crate — monocrate policy). Model 1:1 on probe_rs.rs.
2. Pin wlink v0.1.2: record sha256 per asset (linux-x64.tar.gz, macos-arm64.tar.gz, win-x64.zip, win-x86.zip). Gaps: no linux-aarch64, no macos-x64 assets — fall back to nightly tag or document cargo install wlink for those hosts. Note: wlink's nightly advises the win-x86 build on Windows "since it has the Windows driver support" — evaluate which win asset to pin. Install dir: ~/.fbuild/{prod|dev}/tools/wlink/.
3. Ch32vDeployer implementing Deployer: wlink flash <firmware.bin> (auto-detects chip; flashes to 0x08000000 for raw .bin — verified in wlink source). Wrap with run_command_blocking + timeout like run_probe_rs_download.
4. Replace the fix(ch32v): report deploy limitation honestly #1115 error arm in crates/fbuild-daemon/src/handlers/operations/deploy.rs with Ch32vDeployer construction. Until then (or on wlink-not-found), keep the manual-flash message — and consider honoring monitor_after on that specific failure so fbuild deploy --monitor still attaches after a manual flash (today the error path returns before the monitor block, deploy.rs:958-978).
5. Probe identity via the FastLED/boards registry only (repo rule — no VID/PIDs in fbuild). WCH-Link RV mode = 1a86:8010, DAP mode = 1a86:8012. Blocked on the FastLED/boards registry issue (linked from the meta) — today the published usb-profiles.json has zero WCH entries, so port auto-selection warns "no serial port matched" and preemption never fires for Ch32v.
6. Post-deploy: flashing goes over the Link's vendor interface, so the Link's CDC COM name survives → default post_deploy_recovery is fine when monitoring through the probe. A CH32V208 running native USB-CDC re-enumerates with a new COM after reset — return the re-enumerated port in DeploymentResult.port (the Teensy deployer pattern; deploy.rs:983-998 already prefers deploy_post_port).
7. UX detail: a WCH-LinkE stuck in DAP mode (1a86:8012) is invisible to wlink — detect and hint wlink mode-switch (or the ModeS-key procedure).

Bench-day notes (until this lands)

fbuild build → flash manually with wlink flash <project>/.fbuild/build/<env>/firmware.bin → monitor via fbuild serial probe read (see the monitor streaming issue). Windows: WCH-LinkE RV mode needs the WinUSB driver (installed by WCH-LinkUtility/MounRiver); probe firmware ≥ 2.15; an old CH549-based WCH-Link cannot flash V003/V006/X035/L103 at all — bring a LinkE.

Acceptance

• fbuild deploy tests/platform/ch32v203 -e ch32v203 with a WCH-LinkE attached flashes and the board runs.
• fbuild deploy --monitor attaches the monitor post-flash.
• V003 (1-wire SDI) and V203 (SWD) both flash via the same path.
• No hardcoded VID/PID in fbuild code (registry-driven).

History: #1105 (Phase 1 = honest error, landed in #1115). Found/refreshed during the 2026-07-21 CH32V bench-readiness sweep.

[zackees]

Parent meta: #1130 (2026-07-21 CH32V bench-readiness sweep).