docs/cfg: IDCODE.md and openocd cfgs carry the wrong AX7203 JTAG IDCODE

[gHashTag]

The board-truth doc and two OpenOCD cfgs disagree with the verified IDCODE, which risks JTAG scan rejection and misleads any agent grepping for board truth.

Wrong

• docs/IDCODE.md:5 — IDCODE = 0x13631093 (should be 0x13636093)
• docs/IDCODE.md:13 — part field 0x3631 (should be 0x3636)
• docs/IDCODE.md:19-21 — bit decomposition matches the wrong 0x13631093
• fpga/openxc7-synth/flash.cfg:10 and openocd.cfg:10 — -expected-id 0x0372e093 (that is XC7A35T/Arty, matches neither the 100T nor the 200T on this board)

Correct (already the SSOT elsewhere in-repo)

• specs/boards/ax7203_full.t27:10 — idcode 0x13636093 ("VERIFIED via OpenOCD + AL321 2026-06-24")
• fpga/openxc7-synth/ax7203_al321.cfg:2 — 0x13636093 (Artix-7 XC7A200T-FBG484-2 rev 1)

Fix = reconcile the doc + stale cfgs to 0x13636093 (part 0x3636). Doc/config only; not .tri-generated; do not touch author attribution.

[gHashTag]

Correction after reading the full IDCODE.md — do NOT desk-edit this.

0x13631093 is not a typo: 0x3631 is the legitimate XC7A100T rev-1 part field. IDCODE.md is internally consistent — it documents the QMTech Wukong (100T, 0x13631093) as the main board and separately, correctly lists the AX7203 (200T, 0x13636093) at lines 37/39-41. Both values are real Artix-7 IDCODEs.

So this is a hardware-identity question, not a documentation typo: which board is the project's actual JTAG target? And -expected-id 0x0372e093 in flash.cfg/openocd.cfg is not a valid IDCODE for any Artix-7 part (35T=0x0362D093, 100T=0x03631093, 200T=0x03636093), so its correct replacement is board-dependent too.

Per the project debugging doctrine (identity before shared medium; never codify a second truth over a first; the W12 20h failure was a misread identity collision), the right resolution is an independent JTAG scan of the physically-connected board (openocd -f ax7203_al321.cfg -c "init; scan_chain; shutdown"), then reconcile IDCODE.md + the stale cfgs to whatever the silicon actually reports. That needs the board in hand — not a blind edit from source. Reframing this issue accordingly; leaving it open for whoever has the hardware.