docs(v4.0.0): ruling -- a v4 word's code is the node's, its accounts the kernel's

Captain Bob, 2026-10-05.  For each word on a node the kernel keeps v3's own
DictEntry record, joined by word ID; v3's physics, heartbeat, ACL words,
Stadium word layer and parity run on the records unchanged.

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

docs/v4.0.0/V3-PARITY.md

@@ -418,6 +418,32 @@ The second half is recorded as said and is not yet designed. It bears on
 the open question of section 1e — what moves control between nodes, and
 when — which `ENGINE.md` leaves to step 6.
 
+## 1j. Where a v4 word's accounts live (ruled 2026-10-05)
+
+**Found:** `struct VM` (`v3/include/vm.h`) is both the record the kernel
+keeps for a VM and v3's engine state. The kernel and the physics code work
+directly on dictionary records: about 30 source files reach into a
+`DictEntry`'s fields, several hundred times. The heartbeat's decay walks
+the record list by `link` and resumes by `word_id`; parity hashes it; the
+kernel pins `BIRTH` by setting two of its fields. A v3 word's accounts are
+that C record: `execution_heat`, `physics`, the four ACL fields, the
+transition metrics, the word ID. A v4 word has no such record.
+
+**Put to Captain Bob:**
+A — the code is the node's and the accounts are the kernel's, joined by
+word ID: for each word on a node the kernel keeps v3's own `DictEntry`,
+every account field as it is; the node tells the kernel when a word is
+defined or forgotten; at each `call` the kernel does on the record what
+v3's inner loop does; v3's physics, heartbeat, ACL words, Stadium word
+layer and parity run on the records unchanged.
+B — the accounts go into each entry's header in the node's memory, and
+the 30 files change to reach them through accessors.
+
+**Ruling:** "A is good."
+
+Noted with it: on the FPGA a node's counters are meant to be in the fabric,
+not in a kernel record. A is for v4 = v3 now.
+
 ## 2. Row 3: physics and per-word heat
 
 ### 2.1 What v3 does