Root-cause the std79 lockdown gap: likely never engages for any locked identity (FABRIC-3.md §XXV follow-up)

Following up on the messaging-words-not-denied finding: 'MSG-STATUS
ACL-STD79-ALLOWED? .' sent into rajames came back UNKNOWN WORD, not
"denied" -- acl-std79.4th's own supporting words were never compiled
into the VM's dictionary at all.

Root cause, confirmed via the raw boot log: "WARN: block 4998 exceeds
1KB, truncating" fires during every std79-locked identity's own
birth. capsule_exec_payload() parses "Block N" content as everything
from that header to the next "Block N" header or end-of-payload,
truncating at 1024 bytes for both storage and execution.
MINT_RESTRICTED_PERSONALITY is a short (~200 byte) string written
into a zero-padded 4096-byte devblock at mint time; capsule_runcap_
birth() reads back the entire reserved multi-devblock region with no
second "Block N" header anywhere in it to terminate "block 4998"
early, so the parser treats the whole mostly-padding region as one
oversized block.

Confirmed universal, not one identity's quirk: the warning fires
exactly 8 times in a full 9-identity boot -- once per std79-locked
identity (rajames, 00-06; zuse runs natively on Hera, never through
this path) -- and dates back to at least 2026-09-10 in this repo's
own logs, well before this session. The std79 lockdown has likely
never actually engaged, for any of the 8 locked identities, since it
was built.

Not fully closed to the byte: the real content sits at the start of
the oversized block, inside the surviving truncated slice, so
truncating the tail shouldn't by itself stop the head from executing
-- the exact remaining mechanical step (stale leftover data, a
line-boundary artifact, or something else) isn't nailed down yet.

Explicitly not fixed -- documented per Bob's own "stop here, document
it, and continue" call. Security-relevant (an intended lockdown
restricting nothing) and deserves its own deliberate fix with real
test coverage, not a bolt-on to an unrelated change.

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

FABRIC-3.md

@@ -3279,3 +3279,49 @@ workload-identity × placement-mode as two real factors, ephemeral-birth now the
 placement-mode candidate) once BIRTH's own verification (done here) and the ACL gap (flagged,
 not yet fixed) are both accounted for.
 
+**Root-cause follow-up, same day, Bob's own call ("stop here, document it, and continue" moved
+straight to "root-cause the lockdown/messaging gap" as the next thread):** this went further and
+found a real, concrete, universal mechanism, not just a correlation.
+
+`' MSG-STATUS ACL-STD79-ALLOWED? .` sent into `rajames` came back `UNKNOWN WORD:
+'ACL-STD79-ALLOWED?'` -- not merely "MSG-STATUS wasn't denied," but `acl-std79.4th`'s *own*
+supporting words were never defined in this VM's dictionary at all. `UNKNOWN WORD` and "ACL
+denied" are genuinely different failure classes (the former means `FIND` never located an entry
+with that name; the latter means an existing entry's `acl_allow` flag blocked it) -- this rules
+out "the walk ran but missed some words" and points at "the restricted-personality bootstrap
+script itself never successfully defined anything from `acl-std79.4th`."
+
+The raw boot log pinned it precisely: `WARN: block 4998 exceeds 1KB, truncating` fires during
+every std79-locked identity's own birth. `capsule_exec_payload()` (`capsule_loader.c`) parses
+"Block N" content as everything from that header to the *next* "Block N" header or end-of-
+payload, then truncates to 1024 bytes (`LOADER_BLOCK_SIZE`) if it's larger -- both for storage
+*and* for what actually gets executed. `capsule_mint.c`'s `MINT_RESTRICTED_PERSONALITY` is a
+short (~200 byte) string written into a zero-padded 4096-byte devblock at mint time; read back
+by `capsule_runcap_birth()`, which pulls `source_devblocks` worth of raw content (potentially
+several 4KB devblocks) with no second "Block N" header anywhere in that reserved space to
+terminate "block 4998" early -- so the parser treats the *entire* reserved region, mostly
+padding, as one oversized block, exactly matching the observed warning. Confirmed universal, not
+one identity's one-off mint quirk: the warning fires exactly 8 times in a full 9-identity boot
+(logs/20260912-170001) -- once per std79-locked identity (`rajames`, `00`-`06`; `zuse` runs
+natively on Hera and never goes through this path at all) -- and dates back to at least
+2026-09-10 in this repo's own logs, well before this session. **The std79 lockdown has likely
+never actually engaged, for any of the 8 locked identities, since it was built.**
+
+One open question the truncation mechanics alone don't fully explain: the real ~200-byte content
+sits at the *start* of the oversized block, well inside the surviving first-1024-byte slice, so
+truncation discarding the *tail* shouldn't by itself prevent the *head* (the actual `S" acl-
+std79.4th" EXEC` / `ACL-LOCKDOWN-STD79` lines) from executing correctly. Whether stale/non-zero
+leftover data in that reserved region, a line-boundary artifact where real content meets padding
+without a clean terminator, or something else entirely is the specific reason the head doesn't
+execute either is not yet nailed down to the byte -- the warning's universality and exact timing
+match is strong, corroborating evidence for the diagnosis, not yet a fully closed proof of the
+last mechanical step.
+
+**Explicitly not fixed, per Bob's own "document it, and continue" instruction covering this
+whole thread** -- this is a real, significant, security-relevant finding (an intended lockdown
+that isn't actually restricting anything) that deserves its own deliberate fix, not a same-
+session patch bolted onto an unrelated `BIRTH` change. Test coverage worth having once this is
+fixed: an explicit, automated check that `ACL-STD79-ALLOWED?` (or any allowlist word) actually
+*exists* and denies a known off-list word for a live std79-locked identity, rather than trusting
+a clean mint + a clean boot as proof the lockdown engaged.
+