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/FINDINGS.md

@@ -597,6 +597,19 @@ Everything before this section was Python-side or a headless `-video none` run.
 This is the first time pixels reached an emulated X68000 screen, and it produced
 four hardware facts and one blocker that no amount of reasoning would have found.
 
+**Scope — read this before quoting the result.** The X68000's *video* hardware
+did the rendering: CRTC, GVRAM page decoding and the 15-bit+I palette lookup are
+all genuinely emulated, which is why the output is bit-exact against the
+hardware's colour math. But the pixels were written into GVRAM by a MAME Lua
+script calling `SP:write_u16()` — the host poking emulated memory. **No 68000
+instruction was executed to draw this frame.**
+
+The equivalent is proving a framebuffer works by writing to it from a debugger.
+It says the display path is correct; it says *nothing* about whether the 68000
+can fill that framebuffer in time. Lua writes cost zero 68000 cycles, so the 38%
+full-frame blit estimate that the entire CPU budget rests on remains completely
+unvalidated. That is next step (2), the decoder skeleton, and it is untouched.
+
 Reproduce:
 ```
 python3 tools/bench/prep_frame.py <framedir> tmp/frame.bin 0

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`.