docs(v4.0.0): the Stadium as the frame; blocks -- a v4 node asks by number

Records that compudynamics is the kernel's Stadium (words, VMs, blocks,
messages and ACLs all patrons of one engine), v3's block subsystem as
built, and the ruling of 2026-10-05: a v4 node only asks for a block by
number; ownership, ACL, physics and devices stay on the kernel's side under
the VM's identity.

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

docs/v4.0.0/V3-PARITY.md

@@ -133,6 +133,60 @@ not this step.
 node prints. That is a work-around for the node owning what the kernel
 owns, and it goes when the engine takes the VM's place.
 
+## 1c. The frame: the Stadium
+
+`FABRIC-2.md` section B: "words are stadium patrons, VMs are patrons,
+blocks are patrons, messages are stadium patrons, all should be operated on
+by THE SAME ENGINE."
+
+- A patron is one 64-byte cell of nine wires: identity, heat, TTL, pin,
+  link, behaviour, mass, payload, contains
+  (`kernel/include/starkernel/vm/stadium.h`).
+- Heat is a conserved share of 1.0; K is that conservation.
+- The behaviour is what happens when a patron leaves: words and VMs `COOL`,
+  blocks `MIGRATE`, messages `DELIVER`, ACLs `EXPIRE`.
+- A cell never holds the thing itself, only its identity and heat. A word's
+  code stays in the dictionary; a block's bytes stay in the block
+  subsystem.
+
+Compudynamics is therefore the kernel's Stadium, not something inside the
+VM engine. The engine's part is to report what it executes: in v3,
+`stadium_word_dispatch(vm, word_id, tick)` from the inner loop.
+
+**Reading of the opcode ruling (section 2.7) in this frame, stated to
+Captain Bob 2026-10-05 and not corrected:** on v4 that report carries an
+opcode, and a VM's word patrons become its 32 opcode patrons.
+
+## 1d. Blocks (discussed and ruled 2026-10-05)
+
+**v3, as built:**
+
+- One block address space in kernel C (`v3/src/block_subsystem.c`): fast
+  RAM at 0 to 2047, the ramdrive, Artemis's virtio disk, USB drives,
+  chained.
+- Every block has metadata (`blk_meta_t`): the owner's fingerprint,
+  `acl_allow`, `acl_ttl`, a write count, chain links.
+- Blocks are patrons: `BLOCK`, `BUFFER` and `UPDATE` call
+  `stadium_block_dispatch` with the LBN; heat drives migration and wear
+  levelling (`kernel/src/vm/stadium_blocks.c`).
+- Artemis is the Tripod leg that owns persistent storage.
+- Identity lives there: a keypair Zuse mints onto a thumbdrive; its
+  fingerprint is stamped on every block it claims at first touch, behind
+  the home-blocks fence; the disk's genesis signature is how the kernel
+  knows Artemis's disk.
+
+A v3 VM's block words ask the kernel's block subsystem for a block and get
+a buffer back. Ownership, ACL, physics and devices are the kernel's.
+
+**Ruling (Captain Bob, "yes"):** a v4 node only ever asks for a block by
+number. Everything about who may have it is decided on the kernel's side,
+under the VM's identity. The device chain, metadata, first-touch claim,
+ACL, migration and the Stadium touch stay where they are.
+
+**What this says about the lone-node boot.** It gives the node a bare RAM
+array behind its four block registers (D-19), which skips the address
+space, the metadata, the owner, the ACL and the Stadium.
+
 ## 2. Row 3: physics and per-word heat
 
 ### 2.1 What v3 does