re: WITHDRAW "the guest presents at 30 fps" -- the clean result WAS the failure mode

Published this morning, withdrawn the same day. The measurement was real;
the inference was not established.

My own pre-registration named three ways the instrument could lie and
guarded two. The third -- "the guest may be frame-locked to its own
presentation rather than to the movie clock" -- is the one that occurred,
and a perfect 1.0000 is exactly what it produces: a triple buffer rotating
once per present gives run-length 1 at ANY frame rate. So the measurement
cannot separate a 30 fps guest decoding one movie frame per present from a
60 fps guest rotating a buffer per present.

The methodological error is the part worth keeping. I wrote the guard down,
saw a result so clean it had no tail, and read the cleanness as strength. A
clean result on an instrument whose key assumption is unguarded is not
confirmation -- the cleanness may be the failure mode's own signature. Both
guards I did build tested how the buffer was READ; neither tested whether a
buffer change means a decode.

What surfaced it: the draw log carries a per-frame gtick marker I had not
noticed. It is host time rescaled (Clock::QueryGuestTickCount is
host_tick_count * guest_tick_ratio, scalar 1.0), so it is a wall clock and
cannot be read as a rate -- but its SHAPE has no phase. Xenia locks vblank
to 60 Hz, and the present interval is ONE vblank 71.7% of the time and two
24.6%. A guest hard-locked to 30 fps presents every second vblank and would
put the mass at 2.

I am NOT replacing it with 120. Three routes now disagree: the withdrawn
movie cadence says 60, the vblank cadence says ~120, and
title-plate-delay's 120 declared units in 2.13 s measured twice to 6 ms
says ~56. Two of the three must be wrong and I do not know which.
Publishing 120 would repeat the mistake this commit withdraws.

The port is told to keep 60 for now, and told plainly that it is an
authored value rather than a measured one.

The settling experiment is named: hash the movie luma plane's CONTENTS per
present rather than its base address, which separates "the buffer rotated"
from "a frame was decoded".

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t

docs/port/HANDOFF.md

@@ -500,7 +500,46 @@ constructed in `sub_8220B610` and released in `sub_821A6470`. A *decoder* betwee
 live. That is the next read.
 
 ---
-## ✅✅ 2026-09-01 (eighth) — **KEEP YOUR 60.** The guest presents at 30 fps, measured against a ruler that is not a clock
+## ❌❌ 2026-09-01 (ninth) — **I WITHDRAW the section below. Do NOT act on "keep your 60" — but do NOT change it either**
+
+[`../re/guest-frame-rate-WITHDRAWN.md`](../re/guest-frame-rate-WITHDRAWN.md) ·
+[interval data](../re/data/present-interval-vs-vblank.txt)
+
+I published "the guest presents at 30 fps, so 60 units/s" and told you to change
+nothing. **The measurement was real; the inference was not established**, and the
+flaw is one I wrote into my own pre-registration and then failed to apply.
+
+The unguarded assumption was *"the guest may be frame-locked to its own
+presentation rather than to the movie clock."* **A perfect 1.0000 is exactly what
+that produces** — a buffer rotating once per present gives run-length 1 at any
+frame rate. So the cleanness I read as strength is equally the signature of the
+failure mode. **A clean result on an instrument whose key assumption is unguarded
+is not confirmation.**
+
+What surfaced it: the draw log carries a per-frame `gtick` marker. Xenia locks
+vblank to 60 Hz, and the interval between guest presents is **one** vblank 71.7 %
+of the time and two 24.6 % — a guest hard-locked to 30 fps would put the mass at
+two. The tail at 2+ is dropped frames, the only direction a slow emulator can push.
+
+🔴 **But I am NOT telling you 120.** Three routes now disagree:
+
+| route | says | plate at `t=236` |
+|---|---|---|
+| movie cadence (withdrawn) | 60 units/s | 3.93 s |
+| present interval vs vblank | ~120 units/s | 1.97 s |
+| `title-plate-delay` — 120 units in 2.13 s, twice, to 6 ms | ~56 units/s | ~4.2 s |
+
+Two of the three must be wrong and I do not know which. **Keep your 60 for now** —
+not because I have shown it right, but because changing it on my second guess in
+one day is worse. It is now an authored value, not a measured one, and you should
+know which.
+
+The settling experiment is named in the finding: hash the movie luma plane's
+*contents* per present rather than its base address, which separates "the buffer
+rotated" from "a frame was decoded". The logger needs a small extension for it.
+
+---
+## ❌ 2026-09-01 (eighth) — WITHDRAWN, see above. ~~KEEP YOUR 60. The guest presents at 30 fps~~
 
 [`../re/guest-frame-rate-measured.md`](../re/guest-frame-rate-measured.md) ·
 [pre-registration](../re/guest-frame-rate-preregistration.md) ·