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