FABRIC.md: item 4.4o -- 640x480 scroll-box centering math computed

Pure geometry, no code change. Blocking question checked first: both
4.4n CANVAS heights (688px amd64, 488px aarch64/riscv64) clear the
480px minimum, so no architecture fails the fit.

amd64: box raster top-left (320,104), 320px side margins, 104px
top/bottom margins.
aarch64/riscv64: box raster top-left (80,4), 80px side margins, 4px
top/bottom margins (confirms 4.4n's 16px gap choice lands exactly
where predicted).

Also translated both into TTF-TEXT's Cartesian bottom-left-origin
convention for whatever later item issues the actual TTF-TEXT calls:
amd64 bottom-left (320,216), aarch64/riscv64 bottom-left (80,116).

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

FABRIC.md

@@ -5522,7 +5522,7 @@ document and committing that amendment as its own item.*
   > preserve. Any larger gap than 4.4m's ceiling would have failed this; recorded as
   > confirmation the earlier warning held, not a new finding.
 
-- [ ] **4.4o — 640×480 scroll-box centering math within CANVAS.** Layout math computed on top
+- [x] **4.4o — 640×480 scroll-box centering math within CANVAS.** Layout math computed on top
   of `TTF-TEXT`'s own coordinate primitive, which is simpler and already fixed: Cartesian,
   origin at the bottom-left of the **physical framebuffer** (not CANVAS-relative — resolved
   and implemented ahead of this item, 2026-08-11, `ttf_words.c`'s `baseline_y = fb_height() -
@@ -5535,6 +5535,34 @@ document and committing that amendment as its own item.*
   and reports which architecture's CANVAS is too small.
   *Refs:* §27.8.
 
+  > **Done 2026-08-11.** Pure geometry, no code change. **Blocking question checked first, not
+  > assumed clear:** both 4.4n CANVAS heights (688px amd64, 488px aarch64/riscv64) are ≥ 480px
+  > — no architecture fails the fit, so this proceeds to centering math rather than stopping to
+  > report a failure.
+  >
+  > Centered within 4.4n's CANVAS rect (itself top-left (0,0) on both architecture classes, so
+  > centering within CANVAS is centering within the screen minus the strip): margin
+  > = `(canvas_dim − box_dim) / 2` per axis, symmetric by construction.
+  >
+  > **amd64 CANVAS 1280×688:** `x = (1280−640)/2 = 320`, `y = (688−480)/2 = 104` (raster,
+  > top-down — matches this item's own "top-left" phrasing and how `fb_fill_rect()` already
+  > addresses pixels). Box spans raster x:[320,960], y:[104,584] — 320px side margins, 104px
+  > top/bottom margins, both symmetric.
+  >
+  > **aarch64/riscv64 CANVAS 800×488:** `x = (800−640)/2 = 80`, `y = (488−480)/2 = 4`. Box
+  > spans raster x:[80,720], y:[4,484] — 80px side margins, the full 4px top/bottom margin
+  > 4.4n's 16px-gap choice was picked to leave (8px total split 4px/4px top/bottom, confirming
+  > that margin lands exactly where 4.4n predicted, not a new finding).
+  >
+  > **Translated into TTF-TEXT's Cartesian, bottom-left-origin convention** (`y_cartesian =
+  > fb_height − y_raster`, `ttf_words.c`'s own flip), for whatever later item actually issues
+  > `TTF-TEXT` calls to draw within the box — reference corner is the box's bottom-left, matching
+  > that origin:
+  > - amd64: box bottom (raster) = 104+480 = 584 → `y_cartesian = 800−584 = 216`. **Bottom-left
+  >   (320, 216).**
+  > - aarch64/riscv64: box bottom (raster) = 4+480 = 484 → `y_cartesian = 600−484 = 116`.
+  >   **Bottom-left (80, 116).**
+
 - [ ] **4.4p — Three-arch screendump verification of 4.4l–4.4o.** Geometry only — not the
   toggle or scrollback.
   *Done when:* screendump on all three architectures shows the 640×480 box centered within