port: verify-screen was nondeterministic; pin the pulse phase in the harness

Running the full set after the plate fix, press_start returned over3 5021, 8919,
5021 on three identical runs. The plate's looping focus record takes its phase
from time_units, which free-runs, so the captured frame lands wherever the grab
fell -- while the reference renderer cannot pulse at all.

The port is not the thing that is wrong: the pulse is measured and a thing that
pulses does not stop because the screen arrived. ScreenView.loop_phase_units pins
it, negative means free-running and stays the default everywhere, and only the
harness passes --loop-phase=0.

Controlled: pinned, 3 runs identical; free-running, 3 of 4 identical and one
different. That 3-of-4 is why it survived -- it looks deterministic most of the
time, and without the negative control a no-op flag would have been
indistinguishable from a fix.

With the phase pinned press_start reads max 1 / over3 0 OK -- the recorded
baseline exactly. Fifteen of sixteen rows now match.

The sixteenth, title_jp, has genuinely drifted: 155/20498 -> 233/61208,
deterministic, on the Godot side, localized to one 350x396 block at (405,74).
There is no capture of the Japanese title, so I can say the renderers moved apart
but not which moved. Recorded as an ask, not resolved.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF

tools/port/verify-screen

@@ -138,8 +138,24 @@ print(json.load(open("export/"+f))["source"]["build"])' "$name")
   tbm=$("$CLI" screen info "$DISC/dat/GP_TITLE.pak" --build "$build" --all 2>/dev/null \
     | grep -ioc '\.tbm' || true)
 
+  # 🔴 `--loop-phase=0` PINS THE PULSE, AND WITHOUT IT THIS SCRIPT WAS
+  # NONDETERMINISTIC. `press_start` returned `over3` **5021, 8919, 5021** on
+  # three identical runs: the plate's looping focus record rides `time_units`,
+  # so the captured frame lands wherever the grab fell, while the reference
+  # renderer cannot pulse at all.
+  #
+  # ⚠️ The port is NOT the thing that is wrong. A thing that pulses does not
+  # stop because the screen has arrived, and the pulse is measured. What was
+  # wrong is comparing a moving frame against a static one and calling the
+  # difference a regression -- a detector that answers differently each run
+  # teaches its reader to ignore it, which is worse than one that fails.
+  #
+  # So the phase is pinned HERE, in the harness, and nothing about playback
+  # changes: `loop_phase_units` defaults to free-running everywhere else.
+  # ⚠️ It is usually stable -- 3 of 4 control runs agreed -- which is exactly
+  # why this survived: it looks deterministic most of the time.
   godot --path port --resolution 1280x720 -- \
-    "--screen=$name" --pose=rest "--capture=$OUT/$name.godot.png" >"$OUT/$name.log" 2>&1
+    "--screen=$name" --pose=rest --loop-phase=0 "--capture=$OUT/$name.godot.png" >"$OUT/$name.log" 2>&1
 
   convert "$OUT/$name.godot.png" "$OUT/$name.ref.png" \
     -compose difference -composite -colorspace Gray -auto-level "$OUT/$name.diff.png"