Scope the display-path result: no 68000 code drew that frame

The session-3 milestone was written in a way that reads as "the port renders",
which it does not. The video hardware is genuinely emulated and the output is
bit-exact, but GVRAM was filled by a MAME Lua script poking emulated memory,
not by 68000 instructions.

The distinction is load-bearing: Lua writes cost zero 68000 cycles, so nothing
here tests whether the CPU can decode and blit inside 833,333 cycles. The 38%
full-frame blit estimate that the entire budget rests on is still unvalidated.

Only the "Not yet started" list carried this caveat, which was too buried for
a claim this easy to over-read.

Claude-Session: https://claude.ai/code/session_01194oWYW8DQXK1SZ2DnChW6

docs/STATUS.md

@@ -177,9 +177,16 @@ functional models, not timing-accurate; a KB/s figure from MAME measures the
 emulator's scheduler. `docs/BENCHMARK.md` covers the three-tier approach
 (MAME validates the path, derivation bounds it, real hardware settles it).
 
-## Display path — WORKING, verified end to end (session 3)
+## Display path — VERIFIED (session 3). CPU path — still unproven.
 
 The first real frame is on screen: `docs/images/x68k_first_frame_compare.png`.
+
+**What this does and does not mean.** The video hardware is genuinely emulated
+and the render is bit-exact. But GVRAM was filled by a MAME Lua script, not by
+68000 code — no 68000 instruction has drawn a pixel yet. Lua writes cost zero
+68000 cycles, so the 38% full-frame blit estimate underpinning the whole CPU
+budget is still unvalidated. "Verified end to end" applies to the *display*
+path only. See FINDINGS 22 scope note.
 Full write-up in **FINDINGS 22**. Harness: `tools/bench/show_frame.lua` +
 `tools/bench/prep_frame.py`.