feat(boards): both systems on every board image, chosen at boot -- system=v3 or system=v4

boards/BRINGUP.md A6, FABRIC-3 SXLIII (ruled: one image, switch at boot).
A STARFORTH_V4 kernel carries v3 too; system= in the boot arguments
chooses, else the build's default (V4_DEFAULT: 1 for plain STARFORTH_V4
builds as before, 0 for board images).  make boot_image builds both and
always writes starforth.cfg / cmdline.txt with system=v3 first, and cleans
its ISA's objects first -- that clean was removing build/<arch>/SER5, not
the kernel's objects, until fixed here.

Each ISA: v3 by default (hash unchanged), v4 with system=v4 (538/538).
The SER5 image under OVMF: v3 as built, v4 after a one-word edit on it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

boards/BRINGUP.md

@@ -28,7 +28,7 @@ None has been fixed: each needs your word.
 | A3 | **Fixed 2026-10-14.** A USB boot-protocol keyboard is driven (xHCI interrupt endpoint, `SET_PROTOCOL(boot)`), its reports become the same key events as the PS/2 and virtio keyboards, and the console treats a full keyboard as one: Caps Lock and Num Lock as toggles shown on the keyboard's lights, the keypad as digits or navigation, the arrows and navigation block mapped (the line editor itself still has no cursor movement). While a USB keyboard runs, the console services its reports every timer tick. | `kernel/src/usb/usb_kbd.c`, `kernel/src/usb/xhci.c`, `kernel/src/repl.c`; `FABRIC-3.md` XLI | Rehearsed in QEMU on all three ISAs; on amd64 with the USB keyboard the only keyboard. Limits: a keyboard whose first interface is not the keyboard is not used; no key repeat. Several keyboards, on any controllers, each its own. |
 | A4 | **The only disk driver is virtio.** | `kernel/src/virtio/virtio_blk.c`; `kernel_main.c:493` | On hardware Artemis finds no disk ("Artemis: no virtio-blk disk"). What the fleet then does has not been tried even in QEMU: see step 3.3. |
 | A5 | **Entropy:** RDRAND on amd64 only. aarch64 and riscv64 have virtio-rng alone. | `kernel/src/rng/rng.c` | Pi 5 and Mars print the "no entropy backend available" warning; anything that needs random bytes is refused. Minting needs them. |
-| A6 | **The board images cannot build the v4 node.** `make boot_image` has no `STARFORTH_V4` path. | root `Makefile`, `kernel/Makefile` | Ruled 2026-10-13: both systems, switchable. Not built yet. |
+| A6 | **Fixed 2026-10-14.** Every board image carries both systems, v3 and v4, and the boot arguments choose: `system=v3` (as built) or `system=v4` -- one word in `starforth.cfg` on the SER5's and the Mars's stick or card, in `cmdline.txt` on the Pi 5's card. No rebuild to switch. | root `Makefile`, `kernel/Makefile`, `kernel/src/kernel_main.c`, `kernel/src/boot/cmdline.c`; `FABRIC-3.md` XLIII | The SER5 image itself, booted under OVMF: v3 as built, v4 after the one-word edit. The boot says which system runs and why ("System: ..."). |
 
 ### 1.2 SER5
 
@@ -132,9 +132,11 @@ make boot_image TARGET=RASPI  EMERGENCY_CONSOLE_ENABLED=1
 make boot_image TARGET=MILKV  EMERGENCY_CONSOLE_ENABLED=1
 ```
 
-- [ ] **`make clean TARGET=<board>` first.** The switch is compiled in, and objects built
-      without it are not rebuilt when it changes: an image built over old objects boots
-      headless (seen 2026-10-13).
+- [ ] ~~`make clean TARGET=<board>` first.~~ `make boot_image` now cleans its ISA's kernel
+      objects itself (2026-10-14): make does not see a change of compile flags, and an image
+      built over old objects booted headless (2026-10-13) or would have lacked v4.
+- [ ] To boot v4 instead of v3: change `system=v3` to `system=v4` in `starforth.cfg` (SER5,
+      Mars) or `cmdline.txt` (Pi 5) on the medium. The boot prints "System: ..." with the choice.
 - [ ] Each ends with its image in `build/boards/<board>/`. Record `sha256sum` of each.
 - [ ] Confirm the switch took: the image booted in QEMU (3.2) shows a prompt with no
       thumbdrive attached. After a clean build it does (tried on `MILKV`).