docs: the framing said "awaiting approval" after being approved

Two places, not one. The status line said proposed, and §3 still said
Q#FG1 "needs approval before implementation" — while the lane, the
branch, and PR #219 all record it decided as A. A framing that
survives the lane is the durable record; one that describes its own
state wrongly is worse than no record, because it reads as authoritative.

Also records what implementation corrected about the framing rather
than leaving §5.2 describing a witness that was not built: the
time-based settle it specified cannot work, since a settled pmacs
screen emits per-frame bytes forever and "output stopped growing" never
becomes true. The shipped test anchors to content instead, which
excludes startup's clears by construction rather than by timing — and
its repaint-ordering assertion has to be scoped after the new clear,
because the fixture repeats its marker and the suffix opens with the
tail of startup's own frame.

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

docs/full-grid-resync-framing.md

@@ -1,6 +1,9 @@
 # Honoring `full_grid` — QoL Stage 1
 
-**Status: revision 2 — proposed, awaiting approval.** Reported from daily-driver use:
+**Status: revision 2 — APPROVED, IMPLEMENTED, in review as PR #219.**
+Q#FG1 was decided **A**: the sole grid consumer honors the flag by
+resetting style, clearing, then applying spans. Reported from
+daily-driver use:
 zooming a terminal with `Ctrl +/-` leaves the TUI visibly broken —
 stale glyphs where content should be blank, and dead regions where
 content should be.
@@ -180,7 +183,15 @@ is the better answer on the merits:
 - A makes the protocol's documented sentence true, rather than working
   around it.
 
-**Q#FG1 is the one decision that needs approval before implementation.**
+**Q#FG1 — DECIDED: A**, on approval. The consumer honors the flag;
+`full_grid` keeps its sparse-resync meaning and the producer is
+unchanged.
+
+*Implementation note, recorded because it confirmed the reasoning
+rather than merely following it:* the fix is `emit_cell_delta` beside
+`emit_span` and `emit_status_overlay` — no struct change, no generic
+parameter, no new pattern. B would have touched the producer, changed
+what every resync costs on the wire, and left the flag unread.
 
 ---
 
@@ -230,7 +241,29 @@ new pattern.
    blank.
 3. **`full_grid: false` emits neither**, whatever the spans are.
 
-### 5.2 PTY acceptance
+### 5.1a What implementation changed about §5.2
+
+**The time-based settle described below does not work**, and the
+framing said to build it. A settled pmacs screen emits per-frame bytes
+indefinitely, so "output stopped growing" never becomes true — the wait
+simply runs to its deadline. The vterm suite already recorded the same
+behaviour ("a settled screen emits empty diffs forever"); this framing
+did not connect it.
+
+The shipped witness anchors its mark to **content** instead: just past
+the first painted byte of the fixture. That excludes both of startup's
+clears *by construction* rather than by timing — `Frontend::new` clears
+before any frame exists, and the first frame is itself a resync whose
+clear precedes its own spans — so no timing assumption survives in the
+test at all. It is strictly stronger than what §5.2 asked for.
+
+One further correction found by running it: the repaint-ordering
+assertion must be scoped to **after the new clear**. The fixture
+repeats its marker, so the suffix opens with the tail of startup's own
+frame, and an unscoped comparison measures the clear against paints it
+was never meant to precede.
+
+### 5.2 PTY acceptance — as originally framed
 
 `tests/common/pty.rs:42` exposes `resize(rows, cols)`, so the real
 scenario is reachable: spawn pmacs, put distinctive content on screen,