fix(v4.0.0): storage -- what the review of step 6 found

A block request with fewer than two values on the stack is refused; it
had acted on whatever the stack ring held and stopped the node.

Bare metal: when the kernel's chain takes the place of POST's block RAM
the node's two buffers are emptied, so it no longer holds POST's copy of
a block; and the chain's fast RAM is cleared, so a node cannot read what
was in the kernel's heap.

blocks.c is built with each test under that test's own warnings and
sanitizers; it had been left out of both.  The hosted link cleans its
object directory first: it had linked the withdrawn store_v3.o left there
from the day before.

node.h and DECOMPOSITION.md D-19 no longer describe the message device or
the four registers as current.  MESH.md 8.5 records two findings for
ruling: a node's own copy of a block, and a block read over a node's code.

From a clean build: make -C v4 test, sanitize and hosted-check pass;
amd64, aarch64 and riscv64 boot, POST 538 of 538, same hashes, blocks 1
and 2047 clean at the prompt: logs/20261007-085017, -085254, -085636.

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

docs/v4.0.0/MESH.md

@@ -276,7 +276,7 @@ kernel-Hermes's work in v3 and is not decided for the mesh.
 **Ruled 2026-10-06 and 2026-10-07** (Captain Bob). On 2026-10-07 he found
 this section to have left the OS as designed, and brought it back: every
 node asks the kernel directly, as every v3 VM does. What that withdrew is
-in 8.5, so that it is not proposed again.
+in 8.6, so that it is not proposed again.
 
 ### 8.1 The rulings that stand
 
@@ -376,7 +376,24 @@ block number not to exist, and on the real chain it does.
   step 6a.
 - **Cloud stores and real USB drives** wait for their drivers.
 
-### 8.5 Withdrawn 2026-10-07
+### 8.5 Open, for ruling
+
+Found by review of step 6 on 2026-10-07; nothing is built for either.
+
+- **A node keeps its own copy of a block.** `BLOCK` gives the address of
+  one of the node's two buffers, and the kernel is asked only when a block
+  is not in one. In v3 a VM's `BLOCK` gives the kernel's buffer, so every
+  VM sees one copy. Here, if node A has block *n* in a buffer and node B
+  writes it, A goes on reading what it had; and if A then does `UPDATE` and
+  `SAVE-BUFFERS`, all of B's block is overwritten. One node alone cannot
+  see this, and the unit test's readers had never held the block they
+  read.
+- **A block read over the node's own code.** The kernel checks that the
+  256 cells are in the node's memory and nothing more, so a request made
+  by hand with an address in the nucleus overwrites it and the node stops.
+  `!` can do the same; whether the kernel should refuse it is not ruled.
+
+### 8.6 Withdrawn 2026-10-07
 
 Each of these was ruled on 2026-10-06 or stood in this document, and each
 left v3's design. Captain Bob: "something is really off. it sounds like a
@@ -595,7 +612,7 @@ Each is tested, committed and pushed before the next.
      above is step 5 as it was built.
 6. **Storage (section 8): every node asks the kernel for its blocks.**
    **Done 2026-10-07.** It was first built another way and brought back;
-   8.5 says what was withdrawn and why.
+   8.6 says what was withdrawn and why.
    - *The requests* (`v4/include/v4/blocks.h`, `v4/system/blocks.c`). -1
      reads a block and -2 writes one, `( n waddr -- status )`, for any
      node, from the kernel's block subsystem. `v4/tests/test_blocks.c`: 22
@@ -624,8 +641,20 @@ Each is tested, committed and pushed before the next.
      boots, POST 538 of 538, and typed at the prompt: block 2100 written
      and read back, block 3072 read from the disk, a write to it refused,
      a block that is not there. `logs/20261007-081603` (amd64), `-081839`
-     (aarch64), `-082226` (riscv64). The parity hashes are the same on the
+     (aarch64), `-082226` (riscv64); and again after the review's changes
+     below, with blocks 1 and 2047 read clean at the prompt:
+     `logs/20261007-085017`, `-085254`, `-085636`. The parity hashes are the same on the
      three hosted and the three bare-metal systems.
+   - *Review, 2026-10-07.* One reading of the whole step by a fresh
+     reviewer; no critical defect. Changed after it: a block request with
+     fewer than two values on the stack is refused (it had stopped the
+     node); on bare metal the node's two buffers are emptied when the
+     chain takes the place of POST's block RAM (it had gone on holding
+     POST's block 1), and the chain's fast RAM is cleared in the v4 path;
+     `blocks.c` is built under each test's own warnings and sanitizers;
+     the hosted link no longer takes whatever objects lie in its
+     directory (it had linked the withdrawn `store_v3.o`). Two findings
+     are for ruling, section 8.5.
    - **Not as intended yet.**
      - Who may have which block is not checked (8.4).
      - On bare metal the virtio disk is read and not written. v3's
@@ -637,7 +666,7 @@ Each is tested, committed and pushed before the next.
      - The suite's unit test is still not run at 32 bits.
    - **Seen and not changed.** On the v3 path the chain's fast RAM comes
      from `kmalloc` and is not cleared (`kernel_main.c`, where the chain is
-     set up); only the ramdrive is. The v4 path does as v3 does.
+     set up); only the ramdrive is. The v4 path clears its own.
 
    **6a. Storage that changes while running.** Rulings 6 and 8 of
    section 8.1: chains of several devices, the device and chain