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>

kernel/src/kernel_main.c

@@ -482,6 +482,7 @@ static void sk_v4_block_chain(void)
         console_println("StarForth v4: no memory for the block chain");
         for (;;) { }
     }
+    for (i = 0; i < ram_size; i++) blk_ram[i] = 0;   /* a node is not to read what was in the kernel's heap */
     for (i = 0; i < krd_size; i++) krd[i] = 0;
     if (capsule_blk_init(NULL, blk_ram, ram_size, krd) != 0) {
         console_println("StarForth v4: the block chain could not be set up");