Real per-VM log persistence: source attribution + ACL pin (FABRIC-3.md §XXVII)

Wires the previously-unused vm_log_attributed_vm() into LOG-APPEND's kernel
primitive so persisted log records carry a trustworthy source (the real
attributed VM's registry name, or "HADES" pseudo-source) instead of a
caller-supplied, trivially forgeable string. Drops src-addr/src-u from
LOG-APPEND's stack signature accordingly. Pins LOG-APPEND via bare ACL-PIN
in Artemis's own init.4th, matching BIRTH/CAPSULE-BIRTH's precedent for a
privileged word that can't reach the shared, host-portable ACL.4th.

Also fixes two console-banner nitpicks: a mis-rendering em dash (U+2014)
in the boot banner, and drops "Emergency" from the CLI banner text.

Doc corrections to artemis_sig.h/zuse_eligibility_list.h reconciling the
three fixed devblock ranges now in play. LOG-FLUSH (the intended normal
entry point) and level-aware log eviction remain open, flagged not fixed.

Re-verified clean boot to ok> on all 3 architectures after every change.
riscv64 showed one new, unrelated virtio_blk write-timeout anomaly during
Artemis's early physics self-test (self-recovered, boot unaffected,
sector doesn't map to the log region) -- flagged, not investigated.

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

FABRIC-3.md

@@ -3394,3 +3394,76 @@ investigated further this session -- flagged here for a deliberate decision (ret
 `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.
 
+## XXVII. §XXVI follow-on Step 4: real per-VM log persistence -- source attribution wired,
+LOG-APPEND pinned, two console nitpicks fixed, all 3 archs re-accepted (2026-09-13)
+
+**Built this step (present on disk at session resume, after a power failure interrupted the
+prior session mid-verification): a growable, ring-buffered, disk-backed log region for
+Artemis.** `src/starkernel/log_region.c` + `include/starkernel/log_region.h` -- a
+CRC-guarded control header at a fixed `devblock_from_top` constant
+(`LOG_REGION_DEVBLOCK_FROM_TOP_BASE`), slot devblocks growing from 4 up to a 32-devblock
+ceiling (`LOG_REGION_GROWTH_INCREMENT`/`LOG_REGION_MAX_DEVBLOCKS`), FIFO eviction of the
+oldest record once the ceiling is reached. Reached from FORTH via `LOG-APPEND`
+(`capsules/artemis/init.4th`, Block 4860), a thin wrapper around the kernel-only
+`(LOG-APPEND-RAW)` primitive (`log_words.c`). `include/starkernel/artemis_sig.h` and
+`include/starkernel/zuse_eligibility_list.h` were corrected in the same commit to document the
+three fixed devblock ranges now in play (eligibility list: 1-63, `artemis_sig_t`: 64, log
+region: 65-96) after a fixed-offset collision was caught and fixed earlier this session
+(`61755fd`, genesis-stamp/BAM offset) -- the lesson from that bug (state the real bound in
+writing, don't trust "it'll never get that big") applied here too.
+
+**Two policy gaps were identified and closed before this was called done, both raised by the
+user directly rather than found and silently fixed.** First: `vm_log_attributed_vm()`
+(`log_attrib.h`/`vm_core.c` -- save/restore of "which VM is genuinely executing" across nested
+`vm_interpret()` calls, for exactly this attribution purpose) had been built but never called
+anywhere -- confirmed by grep, only its own definition and declaration matched. Meanwhile
+`(LOG-APPEND-RAW)` took a `source-addr`/`source-u` pair straight off the FORTH stack, meaning
+any caller could claim to be any source; trivially forgeable. Fixed: the stack signature
+dropped `src-addr`/`src-u` entirely (`LOG-APPEND ( level ts msg-addr msg-u -- )`, down from six
+stack args to four); `log_word_append_raw()` now calls `vm_log_attributed_vm()`, looks the
+returned VM up by `stadium_vm_id` via `capsule_vm_registry_get()` for its registry `name`, and
+falls back to the fixed `"HADES"` pseudo-source (matching `log_attrib.h`'s own documented
+convention) when no VM is attributed. Second: `LOG-APPEND` had no ACL pinning at all, unlike
+`BIRTH`/`CAPSULE-BIRTH` (both pinned STRICT in `kernel_main.c` after Mama's own birth). Fixed
+with `' LOG-APPEND ACL-PIN` appended directly in `capsules/artemis/init.4th`'s own Block 4860 --
+*not* `ACL-STRICT` first, because that FORTH policy word is defined by `ACL.4th`
+(Block 4002), which only Hera's `init.4th` loads; Artemis never runs `S" ACL.4th" EXEC`, so
+`ACL-STRICT` does not exist in her dictionary at all, only the bare `ACL-PIN` C primitive
+(registered for every VM at bootstrap, `register_acl_words()`) is safely reachable here. Same
+reasoning `ACL-BOOT`'s own comment already gives for excluding `BIRTH`/`CAPSULE-BIRTH` from
+`ACL.4th` -- a kernel-only-or-VM-local privileged word gets pinned locally, not folded into the
+shared/host-portable policy file.
+
+**Still open, flagged not fixed, per this project's report-don't-fix-unprompted discipline:**
+`LOG-FLUSH` -- the word both `init.4th`'s and `log_region.c`'s own doc comments describe as the
+normal way `LOG-APPEND` gets reached ("dispatched by a sender's `LOG-FLUSH` via a genuine
+`MSG-SEND`/`MSG-TICK` round trip") -- does not exist anywhere in the tree; grep for it matches
+only those two comments. The only live entry points right now are the raw primitive itself or a
+manual console call. And eviction is unconditional FIFO with no level awareness -- a flood of
+DEBUG/INFO noise (already flagged separately as needing cleanup, see the production-logging
+memory) could evict real ERROR/WARN history once the 32-devblock ceiling is reached. Both are
+real gaps in what "real per-VM log persistence" should eventually mean, not attempted this
+session.
+
+**Two unrelated console-banner nitpicks, fixed on the same pass at the user's request:** the
+boot banner's em dash (`U+2014`, multi-byte UTF-8) rendered as garbled `â??` on the framebuffer
+console font (`repl.c`, `sk_repl_run()`) -- replaced with a plain space, no dash at all, per the
+user's supplied before/after screenshot. And `"StarForth Emergency CLI"` shortened to
+`"StarForth CLI"` (same line) -- "Emergency" dropped from the banner text itself; the doc-comment
+file headers in `repl.c`/`repl.h` describing the REPL's own purpose were deliberately left alone,
+out of scope for a UI-text request.
+
+**Acceptance: all 3 architectures re-verified clean after every fix above, one at a time,
+foreground, QMP `quit` once each reached its prompt (never a background `&`/`run_in_background`,
+per this project's hard rule -- the Bash tool's own timeout-driven auto-backgrounding on a
+still-running interactive QEMU process was flagged separately as harness feedback, not a
+workaround taken here).** amd64: clean build, boot to `zuse@Hera ok>`, both banner fixes visible
+correctly in the log. aarch64: same, clean. riscv64: same, clean, **with one new anomaly not
+seen on the other two arches** -- a single `virtio_blk: vblk_io timed out (write=1 sector=3040)`
+error during Artemis's own early physics self-test (not log-region I/O; sector 3040 does not map
+to the log region's top-of-disk devblock range). Boot self-recovered and continued to `ok>`
+without further incident. Not investigated further -- flagged here, consistent with this
+project's known pattern of occasional riscv64/TCG timing flakiness (see the unexplained-SIGTERM
+and aarch64 Stadium/COOL-scaling entries elsewhere in this doc), not assumed to be caused by
+this session's changes given the sector mismatch, but also not confirmed benign.
+