FABRIC-2.md: §17.4 framebuffer physics -- confirm still not ripe, correct its real prerequisite

Live console/framebuffer stack has zero dirty-region or heat/decay instrumentation (grepped framebuffer.c/vt100.c/console.c). True prerequisite is item 1.11 (dirty-event granularity), still unstarted, not 'the framebuffer work' generally, which has since shipped. Left open.

FABRIC-2.md

@@ -302,6 +302,23 @@ and recorded.
 - [ ] **§17.4 — the framebuffer utility's internal heat/decay dynamics are undesigned.**
   Explicitly "Open, deferred": not a Stadium patron, but what physics (if any) governs it
   internally was never designed. Not blocking anything.
+
+  > **CHECKED 2026-08-13, still correctly not ripe — precondition refined, item left open.**
+  > The actual FABRIC.md text (end of §17.5, not really §17.4 — that section number is a
+  > loose reference to the same "OPEN, deferred" paragraph) is explicit: "What those
+  > dynamics are is a question for when the framebuffer work actually happens... it should
+  > not be designed speculatively now." The console/framebuffer work (item 4.3/4.4 series)
+  > has since substantially shipped and is live, which looks at first glance like that
+  > precondition is now met. It isn't: grepped `src/starkernel/hal/framebuffer.c`,
+  > `vt100.c`, `console.c` (1,800 lines total) for `heat`/`decay`/`dirty` — zero hits. Every
+  > write is immediate-mode (`fb_scroll_rows()`, `fb_scroll_rect()`, direct glyph blits at
+  > the point of writing); there is no damage list, no dirty-region tracking, nothing a
+  > per-region heat/decay scheme would even attach to yet. That's consistent with Section
+  > A's item 1.11 (dirty-event granularity) still being unstarted — this item's true
+  > prerequisite is 1.11, not "the framebuffer work" in general as originally framed here.
+  > Designing framebuffer-internal physics before the dirty-event mechanism they'd govern
+  > exists would be exactly the speculative work FABRIC.md warns against. Left open, framing
+  > corrected: blocked on item 1.11, not merely deferred.
 - [x] **§23.4 #2 — cell-size validation against a real message shape.** "Check that a typical
   message still fits in one cell" was never done — item 3.1's own done-note confirmed no
   message-patron struct existed yet at the time. This is now checkable: item 4.2 built