re: the title presents at 28.5 fps idle -- the keyframe unit is settled at

1/60 s, and the 60 Hz reading is excluded

ui-keyframe-time-unit.md named its own re-test and nobody had run it: time
300 submitted frames on the IDLE title, where nothing is streaming from
the ISO. Reaching the title is cheap now that one A skips the intro, so
this cost one boot.

Two clean trials: 300 frames in 10.40 s and 10.60 s, i.e. 28.8 and 28.3
fps. That is the same rate as the 27.6 fps measured during the loading
splash, which is exactly the page's own criterion for "the game is 30 Hz
and the unit is 1/60 s". The 60 Hz alternative is now excluded rather
than disfavoured: it needs the emulator at 47% of real time while sitting
idle on a screen the capture says costs 1526 draws over 300 frames, about
five per frame. Nothing there halves an emulator.

So the durations stand as written -- title 4.2 s, main menu 1.1 s, EXTRAS
0.87 s -- and Q1 leaves the handoff's open-residue table. It stays
MEASURED, not decoded: no field on the disc says sixtieths of a second.

One trap, and it nearly cost the conclusion. My first attempt reported
39.5 fps, which sits between the two hypotheses and would have left the
question open. It was a harness bug: I polled the log for a "done" line
rather than for the COUNT of them increasing, so it matched a capture
that had already completed and timed 0.1 s of nothing. METHOD gets the
general form -- a log-polling probe must compare a count, not test for
presence.

docs/re/METHOD.md

@@ -184,3 +184,9 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
   XACT string at all. The names came from the authoring tool and survived into the
   shipped data. Check for the magic before committing to a parser for the format
   the extension advertises.
+* **A log-polling probe must compare a COUNT, not test for presence.** Timing an
+  operation by waiting for its "done" line in a log gives an instant false
+  positive if any earlier run left one there. This produced a confident
+  "39.5 fps" that was really 0.1 s of matching a stale line — and it disagreed
+  with the true 28.5 fps by enough to have flipped a conclusion. Snapshot
+  `log.count(marker)` before starting and wait for it to *increase*.