Move PLOT/FB-WIDTH/FB-HEIGHT registration to Hestia only -- FABRIC-3.6.md task 1.8

Real fix for task 0.8's finding. register_framebuffer_words() was
called unconditionally from register_forth79_words() (word_registry.c),
itself called unconditionally from vm_init_with_host() -- the generic
per-VM bootstrap every VM goes through, with no way to know a VM's
name at that point.

Removed the unconditional call. Added a name-gated call instead in
capsule_birth_baby() (capsule_birth.c), beside the existing
is_fleet_foundation check -- the one place in the birth path where
capsule_name and the newly-allocated VM* are both in scope together:
Hestia gets register_framebuffer_words(), nobody else does.

Positively verified live, exactly as the task's own check demands:
FB-WIDTH via VM-EXEC returns UNKNOWN WORD in Hermes and Artemis, 1280
in Hestia. Confirmed at the fundamental level too: Hera's own base
PARITY:M7.1a word count dropped from 531 to 528 -- exactly the three
words removed -- identical across all three architectures.

Three-arch boot clean: amd64/aarch64/riscv64 all reach [zuse@Hera] ok>,
zero UNKNOWN WORD during boot. mkcapsule --lint capsules/ clean, 38
files / 0 violations (pure C change, no capsule content touched). No
compiler warnings.

Side effect on the vendored hosted build, expected and not a
regression: capsule_birth.c is kernel-only, so the hosted starforth
binary has no Hestia concept and now never registers these words at
all -- confirmed live. framebuffer_words.c's own top comment already
calls this surface "kernel-only, no-op on hosted builds," so the prior
stub registration was already vestigial. Ran a plain `make` sanity
build per CLAUDE.md's own stated purpose for that target; regenerated
lfs/amd64/starforth included here rather than left stale.

Authorized by Captain Bob ("yes").

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

FABRIC-3.6.md

@@ -409,8 +409,40 @@ Hestia; headless policy intact.
       proof the word exists there, since an unknown word can't underflow. `mkcapsule --lint
       capsules/` clean, 38 files, 0 violations. `MANIFEST.md` updated: `init.4th`'s block 2049
       entry no longer lists `fabric.4th`/`font.4th`; `hestia/init.4th`'s entry gains block 4988.
-- [ ] **1.8** — Move `PLOT`/`FB-WIDTH`/`FB-HEIGHT` registration to Hestia's table **only**.
+- [x] **1.8** — Move `PLOT`/`FB-WIDTH`/`FB-HEIGHT` registration to Hestia's table **only**.
       *Check:* **positively verify** a non-Hestia VM calling `PLOT` gets `UNKNOWN WORD`.
+      2026-09-19 · `logs/20260919-173129/amd64/`, `logs/20260919-173251/aarch64/`,
+      `logs/20260919-173420/riscv64/` — all three reach `[zuse@Hera] ok>`, zero `UNKNOWN WORD`
+      during boot. This is the real fix for task 0.8's finding: `register_framebuffer_words()`
+      (`src/word_source/framebuffer_words.c`) was called unconditionally from
+      `register_forth79_words()` (`src/word_registry.c:139`), itself called unconditionally from
+      `vm_init_with_host()` — the generic per-VM bootstrap every VM goes through, with no way to
+      know a VM's name at that point. **Removed the unconditional call**; added a name-gated
+      call instead in `capsule_birth_baby()` (`src/starkernel/capsule/capsule_birth.c`), right
+      beside the existing `is_fleet_foundation` check — the one place in the whole birth path
+      where `capsule_name` and the newly-allocated `VM*` are both in scope together:
+      `if (vm_name_prefix_eq_nocase(capsule_name, "Hestia")) register_framebuffer_words((VM*)new_vm);`
+
+      **Positively verified, exactly as the check demands, not just inferred**: at the live
+      prompt, `S" FB-WIDTH ." S" Hermes"/"Artemis" VM-EXEC` both return `UNKNOWN WORD:
+      'FB-WIDTH'`; the identical call against `"Hestia"` returns `1280`. Confirmed at the
+      fundamental level too: Hera's own base `PARITY:M7.1a` word count **dropped from 531 to
+      528** — exactly the three words removed — identical across all three architectures
+      (`hash=0xb3b23dc361371c97`, `latest_id=697`). Hermes/Artemis/Hestia `dict_hash` all moved
+      accordingly and are identical cross-arch.
+
+      **Side effect on the vendored hosted build, expected and not a regression**: `capsule_birth.c`
+      is kernel-only (`src/starkernel/`), so the plain hosted `starforth` binary has no Hestia
+      concept and now never registers these words at all — confirmed live (`echo "FB-WIDTH ."
+      | ./build/amd64/standard/starforth` → `UNKNOWN WORD: 'FB-WIDTH'`). `framebuffer_words.c`'s
+      own top comment already calls this surface "Kernel-only; no-op on hosted builds," so the
+      prior stub registration there was already vestigial — this tightens it to match its own
+      documented intent rather than breaking anything real. Ran a plain `make` sanity build to
+      confirm the vendored hosted target still compiles and links clean (CLAUDE.md's own stated
+      purpose for that target); `lfs/amd64/starforth` regenerated as a result and included in
+      this commit since it would otherwise sit stale against the source that produced it.
+      `mkcapsule --lint capsules/` clean, 38 files, 0 violations (no capsule content changed —
+      this task is pure C). No compiler warnings on either edited file.
 - [ ] **1.9** — Assert §XVIII.6's headless invariant: Hestia's birth sets no
       `g_wirebind_attached_username` and mints no proxy. *Check:* boot headless, no thumbdrive,
       **no prompt appears**.