fix(kernel): the block chain's fast RAM is cleared on the v3 path

It came from kmalloc, which does not clear what it hands out; only the
ramdrive beside it was cleared.  A VM's BLOCK on blocks 0 to 2047 read
whatever had been in the kernel's heap.  The v4 path already cleared its
own.

Accepted on the v3 configuration: amd64, aarch64 and riscv64 reach the
zuse prompt, no UNKNOWN WORD, PARITY:M7.1a hash 0x08873e0f44b7cb2a on all
three, as before.  logs/20261007-140609, -140735, -140946.

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

docs/v4.0.0/MESH.md

@@ -753,9 +753,14 @@ Each is tested, committed and pushed before the next.
        has neither Artemis nor Zuse yet.
      - POST is still a capsule Hera loads; step 6b.
      - 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 clears its own.
+   - **Seen, and fixed 2026-10-07** ("no bad code is ever released"). On
+     the v3 path the chain's fast RAM came from `kmalloc`, which does not
+     clear what it hands out, and only the ramdrive was cleared: a VM's
+     `BLOCK` read what had been in the kernel's heap. `kernel_main.c` now
+     clears it, as the v4 path already did. Three v3-configuration boots,
+     `PARITY:M7.1a` hash `0x08873e0f44b7cb2a` unchanged:
+     `logs/20261007-140609`, `-140735`, `-140946`. The boots show nothing
+     was broken; they do not read a block at the prompt.
 
    **6a. Storage that changes while running.** **Withdrawn 2026-10-07**
    (section 8.7): what it was to build is not how v3 does it. Drives that