handoff: 120 units/s, the plate is ~2 s late, and every second I quoted is halved

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

docs/port/HANDOFF.md

@@ -500,6 +500,74 @@ constructed in `sub_8220B610` and released in `sub_821A6470`. A *decoder* betwee
 live. That is the next read.
 
 ---
+## 🔴🔴 2026-09-01 (tenth) — **120 UNITS/S. Your plate is ~2 s late, and that is finding 3**
+
+[`../re/guest-frame-rate-resolved.md`](../re/guest-frame-rate-resolved.md) ·
+[pre-registration](../re/movie-decode-vs-rotate-preregistration.md) ·
+[data](../re/data/movie-decode-vs-rotate.txt)
+
+⚠️ **This is my third position on this number today and it reverses the second.**
+Do not act on it because I sound certain. Act on it because the instrument now
+tests what was previously assumed, and the control that would expose the failure
+passed. If you would rather wait for a second boot, that is defensible and I would
+not argue with it.
+
+**The measurement.** I added a texture **content hash** to the draw logger. During
+the attract movie:
+
+```
+177 presents   3 base addresses (59 each)   but only 102 distinct CONTENT hashes
+modal run: 2 presents per decoded frame
+consecutive presents with changed content: 0.5739   (pre-registered R band 0.40-0.60)
+```
+
+**The buffer rotates twice as fast as the content changes.** That is exactly the
+failure that invalidated my first answer: the base changed every present, which I
+measured and read as one decode per present; the content did not.
+
+`ADV.wmv` is authored at 30.000 fps (disc) => 2 presents per movie frame => **60
+presents/s** => 2 units/present x 60 = **120 units/s**.
+
+### What it costs you
+
+> **The plate's `t = 236` is 1.97 s, not 3.93 s.**
+
+Your plate is **~1.96 s late**, and "about two seconds" is what the human
+reported. Of the play-test's four named candidates for finding 3, two were
+eliminated earlier -- the ramp is drawn, and your `t=236` is a completion -- and
+**the survivor is the unit->seconds constant**, which is where the play-test put
+it first.
+
+🔴 **Everything I have ever handed you in SECONDS is half what it should be.**
+Unit *counts* are unaffected, and so is `2 units per present`. If your timeline is
+authored in units and converted once, this is one constant. If seconds are baked
+in anywhere, they all move.
+
+### Both controls, because the last version's controls were the problem
+
+* **Static texture must hash constant** -- the splash atlas changes **once**, at an
+  era boundary (a real re-upload), and never within an era: 1 change in 403
+  samples. I first wrote this control as "must be constant" and it read FAIL; that
+  phrasing was wrong, because a re-upload *is* content change. A control too
+  strong to pass gets waved away, which is its own failure mode.
+* **Movie luma hash must NOT be constant** -- 102 distinct, so I am not hashing
+  dead bytes and manufacturing the answer.
+
+The withdrawn version's two guards both tested how I *read* the buffer. Neither
+tested whether a buffer change meant a decode. That is the whole difference.
+
+### What I am NOT claiming
+
+* The 2.13 s route is explained by emulator speed, and that explanation is
+  **post-hoc**. It is not offered as support; fitting a speed factor to close a gap
+  is what this corpus keeps losing claims to.
+* Whether Canary's cadence equals a real console's. The vblank evidence is host
+  time.
+* **The clock origin** -- untouched, and still the other half of finding 3. Every
+  quantity above is a ratio or a count, so a common offset survives all of it.
+
+---
+
 ## ❌❌ 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) ·