FABRIC-3.md §X.4: correct a false claim about kmalloc.c lacking block splitting

The claim ("coalesces but doesn't split") was never actually checked
against kmalloc.c -- it was carried over from alloc_kernel.c's own doc
comment about itself and mis-applied to a different file. Asked to fix
it, re-reading kmalloc.c showed allocate_from_block() already has a
complete, unconditional splitting implementation. Nothing was broken;
correcting the record instead of "fixing" working code.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014Ec88YKxxhZGG1RNnune78

FABRIC-3.md

@@ -1656,13 +1656,21 @@ amd64/aarch64/riscv64 (one aarch64 attempt hit an unrelated, already-documented
 hiccup — empty log, boot never left firmware — and passed cleanly on immediate retry with no
 rebuild).
 
-**Not addressed by this fix, still open:** the free list `kmalloc.c` provides is coalescing but
+**Correction, 2026-09-07 (same day):** an earlier draft of this section claimed `kmalloc.c`'s
-still first-fit without block *splitting* — a different, smaller-grained fragmentation lever
+free list "coalesces but doesn't split." That was wrong — never actually verified before being
-than the one that was actually hit here. Per-VM dictionary sizing (shrinking what each
+written, just carried over from `alloc_kernel.c`'s own doc comment about *itself* lacking
-`WIREBIND` user VM's word set actually needs — it currently carries the full set, including
+splitting, mis-applied to `kmalloc.c` too. Re-read on request: `allocate_from_block()` already
-things like `TTF-TEXT`/`SCROLL-BACK`/`KBD-SCAN` a non-console user session may not need) remains
+implements real, unconditional block splitting (`can_split()`/`min_splittable_payload()`) — a
-a separate, unexplored lever, not required by this fix but still worth revisiting if identity
+free block larger than a request needs, with enough leftover to be worth it, gets its remainder
-count grows large enough for it to matter again.
+carved off and threaded back onto the free list as its own block. Combined with
+`coalesce_neighbors()` on every `kfree()`, this allocator already has both halves of real
+fragmentation resistance. Nothing to fix here.
+
+**Not addressed, still open:** per-VM dictionary sizing (shrinking what each `WIREBIND` user
+VM's word set actually needs — it currently carries the full set, including things like
+`TTF-TEXT`/`SCROLL-BACK`/`KBD-SCAN` a non-console user session may not need) remains a separate,
+unexplored lever, not required by anything above but still worth revisiting if identity count
+grows large enough for it to matter again.
 
 **Also flagged, not touched (not asked):** `Makefile.starkernel`'s
 `printf '$(KERNEL_ARGS)\n' > starforth.cfg` breaks when `KERNEL_ARGS` starts with `--` (dash's