ARTEMIS.md: fix stale 'boots live in fleet on every boot' claim, same pattern as TRIPOD.md

capsules/init.4th births no VM but Hera (item 0.1). Artemis's disk device auto-attaches at boot (kernel_main.c M7.pre, real, unchanged); Artemis-as-VM-patron capsule birth does not.

.claude/ARTEMIS.md

@@ -136,8 +136,20 @@ not remember *heat*. Every join is a cold join.
 Implementation happened; this section used to say "do not begin without
 explicit instruction" — that instruction was given and the work is done
 for this scope. `capsules/artemis/init.4th` implements the full flat-pool
-target above, and Artemis boots live in the Tripod fleet (announces ready
-to Hermes) on every amd64/aarch64/riscv64 kernel boot.
+target above.
+
+**Corrected 2026-08-13 — the "boots live in the Tripod fleet... on every
+kernel boot" claim below is stale since item 0.1 (`FABRIC.md` Phase 0),
+same pattern already found and fixed in `TRIPOD.md`.** Two distinct things
+were being conflated: Artemis's block-storage *device* (the virtio-blk
+disk, `disk/artemis.img`) genuinely does auto-attach at the C level at
+boot (`kernel_main.c`'s M7.pre step) on all three architectures — that
+part is real and unchanged. But Artemis-as-VM-patron (capsule birth,
+`CD-INIT`, announcing ready to Hermes) is not automatic: confirmed
+`capsules/init.4th` births no VM but Hera, same as Hermes. Artemis's own
+capsule work below (`ART-BOOT-DETECT`, `ART-FORMAT`, etc.) is real and
+verified, but it runs on demand today, not as a boot-automatic fleet
+join.
 
 Acceptance criteria status, verified 2026-08-02:
 1. ✅ `ART-BOOT-DETECT` — BLANK/LithosAnanke/Unrecognized classification,