fix(ch32v): CH32V203RB links the D6 startup/vector table while HAL compiles as D8

[zackees]

Severity: HIGH (with an upstream-parity caveat) — CH32V203RB links the D6 (low/medium-density) startup/vector table while its HAL compiles as D8. IRQs beyond the D6 set land in the wrong slot.

Problem

genericCH32V203RBT6.json defines -DCH32V203RB -DCH32V203 -DCH32V20x_D8. The pinned core's cores/arduino/ch32/ch32_def_build.h checks #elif defined(CH32V203) before #elif defined(CH32V203xB) — and the RB board never defines CH32V203xB. So the startup TU assembles startup_ch32v20x_D6.S, while every HAL TU compiles as D8 (128K/64K line) via CH32V20x_D8.

Local diff of the two startup files: D8 adds ETH, ETHWakeUp, TIM5, OSC32KCal, OSCWakeUp vector entries that D6 lacks.

Caveat: fbuild is bug-compatible with the A/B reference

Community-PIO-CH32V's RB board JSON has byte-identical extra_flags, so PlatformIO exhibits the same defect. Fixing it is a deliberate divergence from the community platform — record that in the PR description per the A/B-testing policy.

Bench consequence

TIM5/ETH/extended interrupts on an RB board hang or vector to nothing. Only relevant if RB hardware is on the bench and the sketch uses those IRQs; basic GPIO/UART sketches are unaffected.

Fix direction

Swap -DCH32V203 for -DCH32V203xB in the RB board JSON so startup and HAL both resolve D8. Before merging, verify no HAL TU keys off the bare CH32V203 macro (grep the pinned core). V208 is unaffected (CH32V208 → D8W path, verified).

Acceptance

• RB compile response file shows -DCH32V203xB; .d file for the startup TU references startup_ch32v20x_D8.S.
• tests/platform/ch32v208 unchanged (D8W).

Found during the 2026-07-21 CH32V bench-readiness sweep (two audit passes converged independently).

[zackees]

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