repl.c: unify REPL prompt to "[VM name] ok>"

Punch list §25 item 4.4a complete.
Removed the manually-built <Name>)ok>/zuse)ok> prompt suffix from
sk_repl_step()/sk_repl_run() -- console.c's console_putc() already emits a
"[VMName] " prefix at line-start, so the old code was double-printing the
name for non-Hera VMs ("[Hermes] Hermes)ok> "). Now prints only "ok> " and
lets the existing prefix supply the bracket. emergency_console/zuse_session
security semantics unchanged, display-only. Verified: all three
architectures boot live to "[Hera] ok>" (logs/20260811-073408 amd64,
logs/20260811-073448 aarch64, logs/20260811-073542 riscv64).

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

FABRIC.md

@@ -5004,7 +5004,7 @@ document and committing that amendment as its own item.*
   > These are literal `FB_RGB()`-equivalent values for 4.4a/4.4c to consume directly; no
   > implementation performed by this item, per its own "no code" scope.
 
-- [ ] **4.4a — Build `[VM name]` bracket text in the prompt, monochrome.** Replace the two
+- [x] **4.4a — Build `[VM name]` bracket text in the prompt, monochrome.** Replace the two
   existing, mutually inconsistent VM-identity conventions — `console.c`'s per-line `[Name]`
   prefix (`console_set_vm_name()`/`g_active_vm_name`, unaffected/out of scope for non-prompt
   lines) and `repl.c`'s prompt-suffix `<Name>)ok>` (`sk_repl_run()`/`sk_repl_step()`) — with
@@ -5018,6 +5018,29 @@ document and committing that amendment as its own item.*
   CLAUDE.md.
   *Refs:* §27.8.
 
+  > **DONE 2026-08-11.** Caught a bug in the plan before writing it: `console.c`'s
+  > `console_putc()` already fires the `[VMName] ` prefix at line-start whenever
+  > `g_active_vm_name` is set — including on the prompt itself. Printing a second, manually
+  > built bracket (the original plan) would have produced `[Hera] [Hera] ok> `. Fixed by *not*
+  > building a bracket at all — `repl.c`'s `sk_repl_step()`/`sk_repl_run()` now print only
+  > `"ok> "`, letting the existing per-line prefix supply `[VMName] ` for free. This also
+  > explains, and organically fixes, the old non-Hera double-display bug noted in §27.8: the
+  > previous `<Name>)ok>` suffix was *always* being printed after that same automatic prefix,
+  > so a Hermes-attached prompt actually read `[Hermes] Hermes)ok> ` (name shown twice) before
+  > this change. The `is_hera` branch and its `emergency_console` assignment are otherwise
+  > untouched — this is a display-only change, the ACL bypass semantics are identical to
+  > before.
+  >
+  > **Known, intentional gap until 4.4n:** the old prompt distinguished `zuse)ok>` from bare
+  > `ok>` textually. That distinction is not yet visible in the new unified prompt — it moves
+  > to the `(user)` segment, which is explicitly scoped-but-blocked at 4.4n. The underlying
+  > `zuse_session`/`emergency_console` mechanics are unchanged; only the on-screen indicator is
+  > temporarily gone.
+  >
+  > **Regression: clean.** All three architectures boot to `[Hera] ok>`, verified live:
+  > amd64 (`logs/20260811-073408/`), aarch64 (`logs/20260811-073448/`), riscv64
+  > (`logs/20260811-073542/`).
+
 - [ ] **4.4b — Resolve: does prompt color depend on 4.4e?** Investigation, not implementation.
   Read the REPL's actual output path (`console_puts()` → ... → `vt100_putc()` →
   `draw_cursor_glyph()`, all currently `font_8x16.c`) to determine whether a single