fix(boards): drop 'isp' protocol from CH32V003/CH32V006 board JSONs - parts have no reachable ISP bootloader

[zackees]

Severity: MEDIUM (data correctness; becomes user-facing the moment a deployer lands) — six board JSONs advertise an "isp" upload protocol on parts that have no reachable ISP bootloader.

Problem

All 18 CH32 board JSONs uniformly claim "protocols": ["wch-link", "minichlink", "isp", "wlink"]. For the five CH32V003 boards (genericCH32V003A4M6, genericCH32V003F4P6, genericCH32V003F4U6, genericCH32V003J4M6, ch32v003f4p6_evt_r0) and genericCH32V006K8U6 this is wrong:

• No USB peripheral at all (CH32V003 datasheet — the part has no USB block).
• The factory UART bootloader exists but cannot be entered on a blank chip: entry requires the START_MODE option byte plus a running application setting FLASH_STATR.MODE and soft-resetting — there is no BOOT pin. (Sources: CH32V003 DS §1.4.2; wchisp README: "CH32V00x DOES NOT have a USB ISP interface"; basilhussain/ch32v003-bootloader-docs.)
• wchisp stable v0.3.0 has no V00x support at all.

These parts are flashed exclusively via single/two-wire SDI with a WCH-LinkE probe.

Today the arrays are advisory (deploy is unimplemented), but once protocol selection exists, isp on a V003 would route to a nonexistent bootloader.

Note on parity

Community-PIO-CH32V ships the same four-protocol list on its V003 boards — this fix is a deliberate, documented divergence (their list is equally wrong; their isp runner would also fail on V003).

Fix

Remove "isp" from the protocols array in the six V003/V006 JSONs. Leave the other 12 boards (V103/V203/V208/V303/V307/X035/L103 — all have real USB ISP) unchanged.

Acceptance

• The six JSONs list ["wch-link", "minichlink", "wlink"].
• Board-JSON schema tests pass.

From the 2026-07-21 CH32V bench-readiness sweep.

[zackees]

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