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

include/starkernel/zuse_eligibility_list.h

@@ -16,10 +16,26 @@
  * "this is the last devblock in the chain") -- entries are appended by
  * filling the current tail devblock, then chaining a fresh one out of the
  * already-reserved BLK_META_FENCE_INIT budget once it's full. No fence
- * growth logic is needed yet: only 2 of the 128 pre-reserved devblocks
- * are spoken for (0 = genesis marker, 1 = this list's head) and the
- * chain has 126 more slots to grow into before that budget itself would
- * need extending.
+ * growth logic is needed yet.
+ *
+ * CORRECTION (FABRIC-3.md SXXVI follow-on, Step 4, 2026-09-13): the fence
+ * is no longer this list's alone to grow into. artemis_sig_t now owns
+ * devblock_from_top=64 (include/starkernel/artemis_sig.h), and the
+ * per-VM log-persistence ring now owns devblock_from_top 65-96
+ * (include/starkernel/log_region.h) -- both fixed, compile-time
+ * constants, chosen deliberately clear of this list's own growth
+ * direction (chaining upward from devblock_from_top=1). This list's real
+ * remaining headroom is devblocks 1-63 (not "126 more slots" as this
+ * comment used to say): 63 devblocks x ZUSE_ELIGIBILITY_ENTRIES_PER_DEVBLOCK
+ * (127) = 8001 possible eligible identities before ever reaching
+ * devblock_from_top=64 -- vastly beyond any plausible real deployment of
+ * this project, but genuinely unenforced: there is no code-level ceiling
+ * stopping this chain from growing into devblock 64+ if that number were
+ * ever actually approached. Noted here, not silently assumed safe, after
+ * a fixed-offset collision was caught and fixed once already this session
+ * (Artemis's own disk vs. its live BAM, artemis_sig.h's own CORRECTION
+ * comment) -- the lesson being to state the real bound in writing rather
+ * than trust "it'll never get that big."
  *
  * Raw, unpacked 4 KiB devblock -- same convention as
  * zuse_genesis_marker_t/homeblocks_sig_t: real CRC from day one, this