Unify console prompt to [user@VM]; fix real personality-block truncation; correct §XXV's wrong lockdown conclusion (FABRIC-3.md §XXVI)

Investigating the std79 lockdown finding from FABRIC-3.md §XXV led
to a real discovery: WIREBIND births TWO VMs per identity, a console
proxy under the plain username and the actual restricted identity
under <username>~user (capsule_wirebind.c). Every test in §XXV
targeted the console proxy, which was never locked down at all.
Retested against the correct target (rajames~user): the lockdown
works exactly as designed. §XXV's "lockdown never engages" conclusion
was wrong -- corrected here, not deleted, since the mistake and how
it was caught are worth keeping (see the new feedback memory:
confirm which specific VM a name resolves to before concluding
anything, when a subsystem is known to birth more than one VM per
identity).

Two real, separate things found along the way are kept regardless
of that correction:

- capsule_runcap.c: the reserved personality devblock was read in
  full (mostly zero-padding after a short ~200-byte string) with no
  terminator, producing "WARN: block 4998 exceeds 1KB, truncating"
  on every std79-locked identity's birth, universal, since at least
  2026-09-10. Fixed by trimming to the first NUL byte actually found
  -- real, but harmless to execution (real content sat in the
  truncated block's surviving head); it mattered for capsule_id/
  content_hash being computed over padding instead of real content.

- console.h/console.c/repl.c: unified the prompt from a separately-
  computed "[VMName] (user)" into a single "[user@VMName]" line
  prefix -- exactly the ambiguity that caused the original
  misdiagnosis (the prompt showed only the WIREBIND username,
  identical whether USE had targeted the console proxy or the real
  ~user identity). Implemented as a registered callback
  (console_set_user_prefix_provider()) rather than console.c calling
  into WIREBIND/session logic directly, since console.c is a clean
  HAL module with no prior dependency on capsule-level subsystems.

Verified: clean build on all 3 architectures, zero new warnings,
identical dict_hash/capsule_hash to every prior boot this session
(console/prompt-only change). Full 9-identity messaging campaign
re-run end to end: 202s, zero faults, all 8 identities at 99/99
tokens, zero regression.

Also surfaced, not yet acted on: the full campaign's own console
tags now visibly show which VM each identity's tests actually
reached ([zuse@rajames], not [zuse@rajames~user]) -- messaging.4th's
VM-NAMES-INIT registers identities by plain username, so std79-doe.
fth's turn-attractor has been dispatching to each identity's console
proxy, not the actual locked-down identity, since the messaging
rewrite. Flagged for a deliberate decision, not investigated further.

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

FABRIC-3.md

@@ -3325,3 +3325,72 @@ fixed: an explicit, automated check that `ACL-STD79-ALLOWED?` (or any allowlist
 *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.
 
+## XXVI. Correction to §XXV: the lockdown was never broken -- wrong VM tested. Truncation fix
+kept (real, separate bug); unified `[user@VM]` console prefix; a bigger methodology finding
+surfaced along the way (2026-09-13)
+
+**§XXV's "the std79 lockdown likely never engages" conclusion was wrong, and the reason is worth
+recording plainly rather than quietly editing away.** `WIREBIND` births *two* VMs per identity,
+confirmed by re-reading `capsule_wirebind_try_attach()`: a console VM registered under the plain
+username (`capsule_console_birth(username, ...)`), and the actual std79-locked identity VM
+registered as `<username>~user` (`capsule_runcap_birth(dev, sig, user_vm_name, ...)`, where
+`user_vm_name = username + "~user"`). Every test in §XXV targeted `rajames` -- the console proxy,
+which is never locked down at all -- not `rajames~user`, the real restricted identity. Re-run
+against the correct target: `' EXEC ACL-STD79-ALLOWED? .` on `rajames~user` returns `0` (`EXEC`
+correctly denied, exactly as `acl-std79.4th`'s own header comment says it should be once
+`ACL-LOCKDOWN-STD79` finishes) -- the lockdown has been working correctly the whole time. **The
+std79 lockdown gap described in §XXV did not exist. Recorded here as a correction, not deleted,
+because the mistake and how it was caught are worth keeping: always confirm which specific VM
+identity a name actually resolves to before drawing a conclusion from testing it, especially
+when a subsystem (WIREBIND) is known to birth more than one VM per external identity.**
+
+**The `capsule_runcap.c` truncation fix from §XXV is kept -- it's a real, separate bug,
+independently confirmed, just not the cause of a lockdown failure that never happened.** `WARN:
+block 4998 exceeds 1KB, truncating` genuinely fired on every std79-locked identity's birth
+(confirmed universal and long-standing in §XXV); the fix (trimming `source_len` to the first NUL
+byte actually found, since `MINT_IDENTITY_SRC_DEVBLOCKS`'s one reserved devblock is always
+`memset` to 0 before the short personality string is written into it) is correct regardless, and
+matters for a reason independent of lockdown correctness: `desc.content_hash`/`capsule_id` were
+being computed over ~4KB of mostly zero-padding instead of the real ~200-byte content, which
+matters for this project's content-addressing model even though the real content sitting in the
+truncated block's surviving head meant execution itself was never actually affected.
+
+**New: unified console prefix, `[user@VMName]` replacing the separately-computed `[VMName]`
+bracket and `(user)` prompt segment.** Directly motivated by the confusion that produced this
+correction -- console tags already distinguished `rajames` from `rajames~user` correctly the
+whole time, but the *prompt* only ever showed the WIREBIND username, identical regardless of
+which VM `USE` had actually targeted, so a human (or an agent) could not tell from the prompt
+alone which VM a command was about to reach. Implemented as a registered callback
+(`console_set_user_prefix_provider()`, `console.h`/`console.c`) rather than `console.c` calling
+into WIREBIND/session logic directly -- console.c is a clean HAL module with zero prior
+dependency on capsule-level subsystems, and pulling one in for this would have been a real
+layering violation, not just a style question. `repl.c` registers `sk_console_user_prefix()`
+(the same `zuse_session`/`capsule_wirebind_attached_username()` logic `sk_print_prompt()` used to
+compute inline) once at `sk_repl_run()` startup; `sk_print_prompt()` itself now just prints the
+bare `"ok> "` text, since the user segment moved into the shared line prefix that already reaches
+every line, prompt included. Verified live: `[zuse@Hera] ok>` at the bare console, `[zuse@
+rajames~user] ok>` after `S" rajames~user" USE` -- one tag, always accurate about both who's
+logged in and which VM a command actually reaches. Built clean on all 3 architectures, zero new
+warnings; booted all 3, identical dict_hash/capsule_hash to every prior boot this session (this
+change touches only console/prompt code, not the dictionary); re-ran the full 9-identity
+messaging campaign end to end -- 202s (matching the established 194-212s range), zero faults, all
+8 identities at 99/99 tokens, zero regression.
+
+**A bigger methodology finding surfaced while re-verifying the campaign against the new prefix
+format, not yet acted on:** the full-campaign log's own console tags read `[zuse@rajames]`,
+`[zuse@00]`, etc. -- **the plain console-proxy names, not `rajames~user`/`00~user`.**
+`common:messaging.4th`'s `VM-NAMES-INIT` registers identities by their plain username
+(`S" rajames" 1 DOE-IDX>MSG-IDX VM-NAME-REG`, confirmed against the file directly) -- meaning
+`std79-doe.fth`'s messaging-based turn-attractor (§XXI onward) has been dispatching every trial's
+24 tests to each identity's **console proxy VM**, not the actual std79-locked identity VM,
+since the messaging rewrite landed. The turn-attractor's own mechanics (rep-granularity
+batching, priority ordering, K conservation, all of §XXI/§XXII/§XXIII's verification) are
+unaffected by this -- the messaging/Stadium/heat accounting is identical regardless of which
+specific VM receives the dispatched text. What's genuinely in question is the campaign's own
+premise: if the intent was ever to specifically exercise standard-word behavior *inside* a
+locked-down, standards-only environment (as opposed to just "some live VM, whichever WIREBIND
+happens to hand back"), every messaging-based run so far has been testing the wrong one. Not
+investigated further this session -- flagged here for a deliberate decision (retarget
+`VM-NAMES-INIT` to the `~user` identities and re-run, or confirm the console-proxy target was
+actually fine for what this campaign measures) rather than assumed either way.
+