starkernel: item 4.3.3 -- Cartesian coordinate machinery, found and fixed a VARIABLE alignment bug

Adds Module 28 (framebuffer_words.c/.h): PLOT ( x y color -- ), FB-WIDTH,
FB-HEIGHT -- raw hardware-boundary C primitives, kernel-only, no-op on
hosted builds, same pattern as every other module.

Adds capsules/fabric.4th (blocks 4900-4902, mkcapsule --lint clean):
COS45/Z->DELTA/PROJECT/CART-Y/CART-PLOT -- the 45-degree cavalier
orthographic projection and Y-flip, in FORTH per the compose-in-FORTH-first
rule (this is policy, not hardware access).

Found and fixed a second real bug while live-testing CART-PLOT over the
serial socket: defining_word_variable() (defining_words.c) captured
vm->here as a VARIABLE's address with no alignment call first, while
vm_load_cell/vm_store_cell require 8-byte-aligned addresses. This capsule's
VARIABLE ZD landed misaligned (945) purely by chance of what preceded it;
other capsules' variables happened to land aligned by luck, not guarantee.
Real deviation from FORTH-83/ANS, which specifies VARIABLE reserves an
aligned cell. Fixed with vm_align(vm) before capturing addr -- ALIGN
already existed as a word but VARIABLE wasn't calling it.

Verified end-to-end on amd64 via manual serial injection + QEMU screendump:
plotted 4 marker points (origin, +100 X, +100 Y, +50 Z) and confirmed all
landed at hand-calculated raster coordinates, including the diagonal
up-right shift for the Z-axis point -- the projection math is correct, not
just non-crashing. fb/fabric-test-cart-plot.png. 4.3.1's corner diagnostic
still renders correctly in the same shot, confirming no regression.

All three architectures (amd64/aarch64/riscv64) boot clean to ok> with the
DoE completing; dict_hash identical across all three
(0xc7f9adf885e306d2), confirming parity is unaffected.

FABRIC.md item 4.3.3 marked done with full acceptance evidence.

FABRIC.md

@@ -3692,7 +3692,7 @@ document and committing that amendment as its own item.*
   > a Makefile target, per direction — run directly for now. aarch64/riscv64 not covered by
   > this script; not needed for 4.3.1's amd64-only diagnostic.
 
-- [ ] **4.3.3 — Cartesian coordinate machinery.** Origin bottom-left `(0, 0)`, Y-up, plus a
+- [x] **4.3.3 — Cartesian coordinate machinery.** Origin bottom-left `(0, 0)`, Y-up, plus a
   new Z axis (depth-into-screen, not height) and a fixed orthographic projection as a
   placeholder — not the final projection, no perspective/camera work yet. **Angle settled
   2026-08-07: true 45° cavalier.** New C primitives `PLOT ( x y color -- )`, `FB-WIDTH`,
@@ -3700,6 +3700,34 @@ document and committing that amendment as its own item.*
   `capsules/fabric.4th` (blocks 4900+) for `PROJECT`/`CART-Y`/`CART-PLOT`, per the
   compose-in-FORTH-first rule — the transform is policy, not hardware access. *Refs:* §27.3.
 
+  > **Done, 2026-08-07.** `register_framebuffer_words()` (Module 28) adds `PLOT`/`FB-WIDTH`/
+  > `FB-HEIGHT` — kernel-only, no-op on hosted builds, same pattern as every other module.
+  > `capsules/fabric.4th` (blocks 4900–4902, lint-clean per `mkcapsule --lint`) defines
+  > `COS45`/`Z->DELTA`/`PROJECT`/`CART-Y`/`CART-PLOT`.
+  >
+  > **A second real bug found and fixed, not scope creep.** Live-tested `CART-PLOT` over the
+  > serial socket (same injection technique the DoE machinery uses) and hit a silent `ERROR`
+  > on the capsule's own `VARIABLE ZD`, while an identical `VARIABLE` typed live at the REPL
+  > worked fine. Traced to `defining_word_variable()` (`defining_words.c:471`): it captures
+  > `vm->here` as the variable's address with no alignment call first, and `vm_load_cell`/
+  > `vm_store_cell` require 8-byte-aligned addresses. `ZD` landed at `945` (misaligned) purely
+  > because of what preceded it in the capsule; `TESTV`/`ZD2` defined live happened to land on
+  > aligned addresses by luck. This is a real deviation from FORTH-83/ANS, which specifies
+  > `VARIABLE` reserves an *aligned* cell. Fixed with one line (`vm_align(vm)` before capturing
+  > `addr`) — `ALIGN` already existed as a word (`dictionary_words.c`) but `VARIABLE` wasn't
+  > calling it. Fixes every `VARIABLE` in the system, not just this capsule's — other capsules
+  > (`doe.4th`, `init-4.4th`) were landing aligned by luck, not by guarantee. Both hosted and
+  > kernel builds recompiled clean after the fix.
+  >
+  > **Verified end-to-end**, amd64, via the same manual-injection + `screendump` technique:
+  > plotted 4 marker points (origin, +100 X, +100 Y, +50 Z; a 3×3 cluster each for visibility)
+  > and confirmed all four landed at hand-calculated raster coordinates — including the
+  > diagonal up-right shift for the Z-axis point, confirming the 45° cavalier projection math
+  > is correct, not just non-crashing. Screenshot: `fb/fabric-test-cart-plot.png`. 4.3.1's
+  > corner diagnostic still renders correctly in the same shot — no regression.
+  >
+  > Not wired into `init.4th`'s boot chain, per plan — Console isn't a fleet VM yet.
+
 - [ ] **4.3.3a — Q48.16 trigonometry.** `Q.SIN`/`Q.COS` (radian input) added to `q48_16.c`,
   Taylor series after range-reducing into `[-π, π]` — same pattern as this file's existing
   `Q.LOG`/`Q.EXP`/`Q.SQRT`, not a new precedent. Raised 2026-08-07 while scoping 4.3.3: needed