feat(kernel): Artemis and Zuse from one disk -- the stick; virtio Artemis leaves v4

sk_v4_identity.c: a USB drive is this system's stick if its GPT has both StarshipOS partitions and
it is the disk the loader booted from (BootDisk's DiskGUID), or, when the boot was not from a
stick, the first such disk while none is attached. Then: its Artemis partition must carry a good
artemis_sig ('Artemis: the stick's signature is bad -- not used' otherwise), is attached first --
the first disk slot -- ('Artemis: the stick's partition attached'), Zuse's key is read from its
genesis marker, and its identity partition is checked and attached as before. Any other drive,
raw or GPT: 'USB: a drive that is not this system's stick -- not used'. On a pull the identity
partition is detached, then Artemis. sk_v4_identity_boot / sk_v4_run take the loader's BootDisk.
kernel_main.c: no virtio Artemis on the v4 path. kernel/Makefile: ARTDISK= attaches no virtio disk
(every QEMU target); ARTDISK stays for system=v3.

STICK.md 4 amended as ruled (R2): on v4 only this system's stick is used; users' drives minted by
this system's Zuse come with the users design after INSTALL. BRINGUP.md: Secure Boot off on every
PC (ruled 2026-10-28), RDRAND in QEMU, the SER5 smoke-test stick, A4 not on v4.

Tests: new stick_artemis (x3, no virtio disk), stick_zuse, two_sticks (replaces datastick),
artemis_unsigned, raw_ident; changed stick_boot, gpt_zuse, gpt_hotplug, midpull (replug) -- all
failed before, pass after (two test defects found and fixed: the signature's offset, the 63-char
log cut). Regression 20/20. Acceptance: amd64, aarch64, riscv64 to [zuse@Hera] ok>, POST 538/538,
dict_hash 0xfec8c47cfc6f437f; v4 suite and test-32 0 failures.

Plan: docs/v4.0.0/plans/2026-10-27-stick-4-one-disk.md, Task 4.

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

boards/BRINGUP.md

@@ -26,7 +26,7 @@ None has been fixed: each needs your word.
 | A1 | **Fixed 2026-10-14.** The USB controller was matched by QEMU's own IDs (`1B36:000D`) on PCI bus 0 alone. Now: found by its PCI class (`0C/03/30`) on any bus, slot and function; its register window mapped at the size its BAR reports; taken from the firmware through the USB Legacy Support capability (SMIs off); and 64-byte contexts (`CSZ=1`, common on real controllers) laid out instead of refused. Every controller is driven, up to 8 (since 2026-10-14, `FABRIC-3.md` XLII): a stick or keyboard may be in any port. | `kernel/src/usb/xhci.c`, `kernel/src/pci/pci.c`; `FABRIC-3.md` XL | Rehearsed in QEMU with another vendor's controller behind a bridge, all three ISAs. Not rehearsable: the firmware handoff and 64-byte contexts (QEMU's controller has neither). |
 | A2 | **No prompt without a login.** The production default, `EMERGENCY_CONSOLE_ENABLED=n`, keeps the system headless until an identity logs in by thumbdrive. | `Kconfig.heartbeat:68`; `FABRIC-3.md` VIII.1 | With A1, the v3 system never shows a prompt on hardware. A bring-up build must set `EMERGENCY_CONSOLE_ENABLED=1`. |
 | 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. |
+| A4 | **The only disk driver is virtio** (v3). Since 2026-10-28 the v4 boot takes Artemis from the stick over USB, not from virtio (`docs/v4.0.0/STICK.md` §4): on v4, A4 no longer applies. | `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 | **Fixed 2026-10-14.** Every board image carries both systems, v3 and v4, and the boot arguments choose: `system=v4` (as built: v4 is the default) or `system=v3` -- 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: ..."). |
 
@@ -112,7 +112,9 @@ In this order, each as a design for approval first:
 **To know before starting**
 
 - [ ] SER5: Secure Boot is off (`FABRIC-3.md` III says it is on this unit); which key opens
-      the firmware's boot menu; whether there is a serial header.
+      the firmware's boot menu; whether there is a serial header. **Secure Boot stays off for
+      every PC** (Captain Bob, 2026-10-28): the stick's loader is unsigned, and the user
+      instructions say to turn Secure Boot off; there is no shim and no Microsoft signing.
 - [ ] Pi 5: the EEPROM firmware is recent enough to honour `kernel_address` and `os_check`
       (boot Raspberry Pi OS once and note the version).
 - [ ] Mars: the SPI flash holds a U-Boot that scans the SD card for an EFI loader; the boot
@@ -195,7 +197,14 @@ the one QEMU exercises most closely, and the Pi 5's can be rehearsed only in par
 - [ ] Watch for, in order: `StarKernel UEFI Loader`; `GOP: linear framebuffer found`;
       `LithosAnanke v...`; `PMM initialized.`; `VMM initialized`; `APIC: init done`;
       `Timer: init done`; `Kernel heap initialized.`; `Stadium: ...`; POST; the verdict lines.
-- [ ] `rng: backend = rdrand`. In QEMU it says `virtio-rng`; this line is new on hardware.
+- [ ] `rng: backend = rdrand`, as in QEMU since 2026-10-28 (amd64 QEMU runs `+rdrand` and has
+      no virtio-rng).
+- [ ] **The smoke test's stick** (2026-10-28, after the stick's increment 4): `make boot_image
+      TARGET=PC STICK_PAIR=disk/zuse-scratch`, Zuse's minted pair in the stick's partitions;
+      `system=v4 screen=boot` in its `starforth.cfg` once `screen=boot` exists (increment 4,
+      Task 5). Watch for `Boot disk: a StarshipOS stick`, `Artemis: the stick's partition
+      attached`, then `[zuse@Hera] ok>`. The same image boots in QEMU first:
+      `make -f kernel/Makefile ARCH=amd64 qemu-stick STICK_PAIR=disk/zuse-scratch`.
 - [ ] The timer lines differ from QEMU's by design: no hypervisor, so the HPET path runs for
       the first time. S1 is the finding to remember if it stops there.
 

docs/v4.0.0/STICK.md

@@ -47,7 +47,7 @@ and demos.
 | What a try-it session writes persists on the stick until `INSTALL` | §4, §7 |
 | Splash only on screen; the log on serial | §8 |
 | Pulling the stick: headless until it is plugged back in | §7 |
-| **GPT for boot media and installed disks** — overturns `FABRIC-2.md` §F.8 ("GPT dropped entirely") for these two kinds of media; raw identity drives stay accepted | §4 |
+| **GPT for boot media and installed disks** — overturns `FABRIC-2.md` §F.8 ("GPT dropped entirely") for these two kinds of media; on v4 only this system's stick is used (amended 2026-10-28) | §4 |
 | v4 only | §1 |
 | On the stick, `system=v3` is refused: a line says v3 is not on this stick, and v4 boots | §5 |
 | The GPT code runs on every ISA; every `clean qemu` boot attaches a small GPT **data stick** (identity and Artemis partitions) over USB in place of virtio; virtio Artemis leaves v4 | §9 |
@@ -82,8 +82,17 @@ gains the partitions below). Three partitions:
 - **The identity and Artemis formats do not change.** Every check that reads them
   (`homeblocks_sig_check`, `capsule_zuse_boot_check`, `artemis_sig_check`, the block
   subsystem) runs unchanged on the partition device.
-- **Raw identity drives stay accepted:** a device with no valid GPT is read as today (the minted
-  scratch pair in `disk/zuse-scratch/`, any v3 identity drive).
+- **Raw identity drives on v4 — amended 2026-10-28** (Captain Bob, ruling R2 of
+  `plans/2026-10-27-stick-4-one-disk.md`): this bullet said "raw identity drives stay accepted",
+  which contradicted "one disk" above. **On v4, Artemis and Zuse come only from this system's
+  stick, and no other drive is attached** — raw or GPT, blank or minted: "USB: a drive that is not
+  this system's stick -- not used". Once Artemis is only on the stick, a raw drive could be Zuse's
+  only as a copy of the stick's own identity partition, and attaching it before the stick would
+  take the first disk slot, where the fence must be. **This is not a "never" for other people's
+  drives:** drives of users minted by this system's Zuse, and checked by WIREBIND against her key,
+  come with the users design after `INSTALL` (Captain Bob, 2026-10-28: an installed v4 system mints
+  and accepts its own users' drives). On `system=v3`, raw identity drives are read exactly as
+  before; v3 reads no GPT at all.
 - **Sizes: a minimum, and dynamic above it** (Captain Bob, 2026-10-26: "pick like the generic size of
   any old ... thumb drive off the shelf ... I want the sizing to be dynamic, so like a minimum and then
   ... no max or reasonable max size"; "all to Artemis, identity stays at 500 MiB"). Set in one place,