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

kernel/src/kernel_main.c

@@ -669,6 +669,11 @@ static void kernel_main_deep(BootInfo *boot_info) {
         /* Pre-zero the ramdrive buffer (no memset in freestanding context) */
         size_t krd_i;
         for (krd_i = 0; krd_i < KRD_BUF_SIZE; krd_i++) krd_buf[krd_i] = 0;
+        /* And the fast RAM, LBN 0..2047.  kmalloc does not clear what it
+         * hands out, so without this a VM's BLOCK read whatever had been in
+         * the kernel's heap (fixed 2026-10-07; found while the v4 node was
+         * given these blocks, docs/v4.0.0/MESH.md step 6). */
+        for (krd_i = 0; krd_i < BLK_RAM_SIZE; krd_i++) blk_ram_buf[krd_i] = 0;
         /* Init block subsystem (RAM + ramdrive) */
         capsule_blk_init(mama_vm, blk_ram_buf, BLK_RAM_SIZE, krd_buf);
     }