ch32v: CH32V006 builds as a CH32V003 — series mapped to system/CH32V00x instead of CH32VM00X (16K/2K linker script on a 62K/8K chip)

[zackees]

Part of the CH32V pipeline audit (#1102).

What happens

series_to_system_dir() in crates/fbuild-build-mcu/src/ch32v/orchestrator.rs maps any ch32v*/ch32l* series by replacing the last digit with x:

"ch32v006" -> "CH32V00x"

But the CH32V006 does not live in system/CH32V00x upstream. The pinned core (d7671623) ships a separate system/CH32VM00X/ family dir for CH32V002/004/005/006/007/M007, whose Link.ld has the correct active MEMORY region for V006:

/* CH32V006_CH32V007_CH32M007 */
FLASH : LENGTH = 62K
RAM   : LENGTH = 8K

Because the mapping lands on CH32V00x (the CH32V003 family), building genericCH32V006K8U6 uses:

• the CH32V003 HAL (system/CH32V00x headers/sources) instead of the V006 HAL,
• the CH32V003 linker script — 16K flash / 2K RAM — on a 62K/8K chip,
• the CH32V003F4 variant (that part is a documented, deliberate fallback in resolve_variant_dir, but it was forced by the same family confusion).

discover_system_includes only logs a debug line when its guess doesn't exist, and the linker-script path is built unconditionally, so nothing fails — the V006 board silently builds as a V003.

Why it matters — worked example

A user with a CH32V006K8U6 (62K flash / 8K RAM per the datasheet; the board JSON correctly says rom: 63488, ram: 8192) writes a 20K sketch. The size check says "20K of 62K — fine", the link fails with FLASH overflow at 16K. Anything that squeezes under 16K runs against the wrong HAL (V003 RCC/peripheral layout) and can only touch 2K of the 8K RAM.

Related nits (fold into the fix)

• genericCH32V006K8U6.json extra_flags defines -DCH32VM0X -DCH32VM0x — these look mistyped: the upstream family macro/dir convention is CH32VM00X/CH32VM00x (each missing a 0).
• Once system/CH32VM00X is used, revisit the resolve_variant_dir hack that pins CH32VM00X/CH32V006K8 back to CH32V00x/CH32V003F4 (the "PB_* pins not defined" failure it works around was likely a symptom of compiling that variant against the V003 build).
• test_series_to_system_dir has no case for ch32v006 — add one asserting CH32VM00X.

Severity: HIGH (46K of flash and 6K of RAM unusable; wrong HAL for the silicon; size accounting contradicts the link).