Console prompt: identity/machine both sides once redirected off Hera

sk_console_user_prefix() (repl.c) previously always returned "zuse"
(or the WIREBIND-attached username) as the left side of the bracket
prefix, regardless of which VM the console was actually pointed at --
"[zuse@rajames]" after USE rajames, always showing the authenticating
superuser rather than the active identity.

Changed on Captain Bob's direct instruction: once the console is
redirected into a WIREBIND identity's own console VM
(console_get_vm_name() != "Hera"), show that same name on both sides
-- "[rajames@rajames]" -- since WIREBIND births the console VM
literally named after the identity, so the identity IS that VM, not a
separate label. At the top level (still on Hera, nothing has
redirected yet), the original zuse_session/WIREBIND-username logic is
unchanged.

An earlier, more ambitious attempt (separate identity/machine tracked
state across every console_set_vm_name() call site) regressed live to
a wrong [zuse@Artemis] prompt and was fully reverted before reaching
any acceptance run -- the landed fix needed none of that new state,
just this one function.

Verified live on all three architectures: [zuse@Hera] at the top
level and after a live WIREBIND attach (before USE), [rajames@rajames]
after USE rajames, with task 3.9's Stage D relay still firing
correctly on top of it. Zero UNKNOWN WORD, dict_hash unaffected
(display-only change).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

FABRIC-3.6.md

@@ -1323,6 +1323,51 @@ kept as the reproduction — a second identity drive attached at boot is what ex
 default single-drive boot this whole document's other acceptance runs used never will. Task 3.9
 is paused pending Captain Bob's decision on when this gets fixed.
 
+**2026-09-22, out-of-band request during task 3.9's own verification — console prompt format
+changed on Captain Bob's direct instruction, not a reshuffle task, no task number.** The bracket
+line prefix (`console.c`'s `emit_prefix()`, unchanged) used to read
+`[<session-owner>@<active console/identity>]` — e.g. `[zuse@rajames]` after `USE rajames`, always
+showing the authenticating superuser on the left regardless of which identity the console was
+actually redirected to. Corrected across several rounds of live clarification to: once the
+console is redirected into a WIREBIND identity's own console VM (`console_get_vm_name() !=
+"Hera"`), show that same name on **both** sides — `[rajames@rajames]`, not `[zuse@rajames]` —
+because WIREBIND births the console VM literally named after the identity
+(`capsule_console_birth()`), so the identity *is* that VM, not a separate label layered on top of
+it ("R.A. James is also a VM," Captain Bob's own reasoning). At the top level (still on Hera,
+nothing has redirected the console yet — e.g. a live WIREBIND attach announced but not yet
+`USE`'d into), the original `zuse_session`/`capsule_wirebind_attached_username()` logic is
+unchanged, since Hera's own name doesn't say who's driving her.
+
+**First attempt regressed live and was reverted before being carried into any acceptance run.**
+An initial, more ambitious design (separate "identity" vs. "machine" tracked state, touching
+every `console_set_vm_name()` call site across `BIRTH`/`RUN`/`VM-EXEC`/`VM-CALL`/`CONNECT-*` in
+`mama_forth_words.c`) produced a wrong `[zuse@Artemis]` prompt live, because the machine segment
+only ever got updated on the way *in* to a temporary excursion (e.g. into Artemis's own context
+during a birth), never restored on the way back out for a "restore to a non-fleet-member name"
+case. Caught by `advisor()` before it reached any committed acceptance run; fully reverted
+(`console.c`, `console.h`, `repl.c`'s registration all restored byte-for-byte to their prior
+committed state) rather than patched forward. The landed fix, below, needed none of that new
+state.
+
+**Landed fix: `sk_console_user_prefix()` alone** (`repl.c`) — when `console_get_vm_name() !=
+"Hera"`, return it directly (emit_prefix() then prints it on both sides of the `@`, unchanged
+otherwise); else keep the original `zuse_session`/WIREBIND-username logic. Zero new state, zero
+other call sites touched. Verified live, interactively, on all three architectures (same
+mint → WIREBIND-attach → `USE` → typed console line shape as task 3.9's own acceptance):
+`[zuse@Hera]` at the top level and immediately after a live WIREBIND attach (before `USE`),
+`[rajames@rajames]` after `USE rajames`, Stage D relay (task 3.9) still fires correctly on top of
+it. Zero `UNKNOWN WORD`, `dict_hash` identical to every prior acceptance run in this document
+(unaffected — this is a display-only change). Logs:
+`logs/20260922-133732/amd64/`, `logs/20260922-134049/aarch64/`, `logs/20260922-134638/riscv64/`.
+
+**Separately raised, not yet actioned: background diagnostic console noise
+(`[Hestia@Hestia]`/`[Hermes@Hermes]` `INFERENCE: Output validation failed` warnings, `HADES`
+xhci error/warn lines) interleaves visibly with interactive console output**, confirmed live via
+a QMP `screendump` Captain Bob asked for mid-task. Matches this project's own already-tracked,
+not-yet-started item (memory `project_production_logging_cleanup_needed`:
+`console_println()` overuse, much of it should be DEBUG-level). Captain Bob explicitly deferred
+this to after the prompt-format fix landed — genuinely not started, no task number assigned yet.
+
 ---
 
 ## Out of scope, carried for visibility