port: WITHDRAW the leaf rate the same day it was adopted

The Decoder withdrew 0.514: captured frames are presents and the present rate
differs per run -- the same animation took 1168 frames in one capture and 600 in
another, 1.947x apart, with that run's own baseline moving 1.953x alongside. So
it measured the capture's pacing, not the game. rate is null again (identity).

📌 The tell was there before the withdrawal and neither of us weighed it. The
human said the animation itself LOOKS correct. A port running 1.0x against a real
0.514x would be twice too fast and they would have said so. Their impression was
evidence against the number and both of us recorded it as a puzzle instead. A
human's impression is weak about magnitudes and strong about gross wrongness.

start_units 40 kept but marked provisional: two captures agree in RATIO form,
which needs no clock and survives the withdrawal, but converting the ratio to
title units needs the title rate, and that is itself in conflict (1.0 units/frame
from ptcopyright's ramp against 0.571 from the plate's, 1.75x apart).

Kept rather than reverted because 0 is not a measurement either -- it is the
unexamined assumption that the leaf shares the screen's clock.

authored/rendering.json

@@ -172,36 +172,37 @@
   "leaf_clock": {
     "title": {
       "start_units": 40.0,
-      "rate": 0.514
+      "rate": null
     }
   },
   "leaf_clock_why": [
-    "The leaf's clock relative to its screen's: leaf_t = rate * (screen_t - start_units).",
+    "leaf_t = rate * (screen_t - start_units); a null field means 'not measured',",
+    "and rate null is the identity, i.e. the leaf runs at the screen's rate.",
     "",
-    "MEASURED off one draw capture by the Decoder, docs/re/f6-unit8-leaf-clock-in-title-units.md",
-    "on origin/auto/frame-blend-draw-path. Both numbers come from the SAME capture,",
-    "so neither crosses runs.",
+    "\ud83d\udd34 RATE WITHDRAWN 2026-09-02, the same day it was adopted. It was 0.514, from",
+    "the Decoder's f6-unit8. They withdrew it: captured FRAMES are presents, and the",
+    "present rate differs per run -- the same animation took 1168 frames in one",
+    "capture and 600 in another, 1.947x apart, with the run's own baseline moving",
+    "1.953x alongside. So 0.514 measured that capture's pacing, not the game.",
     "",
-    "  start_units 40  -- the game's leaf t=0 is its first drawn frame, 40 frames",
-    "                     after the title's first element draws. The title rate is",
-    "                     itself measured, not assumed: ptcopyright declares a",
-    "                     0->255 ramp over 22 units and rises across 22 frames, so",
-    "                     the title runs 1.000 units/frame and frames and units are",
-    "                     interchangeable there.",
-    "  rate 0.514      -- 600 leaf units across 1168 frames, anchored on the LOOP",
-    "                     WRAP rather than on where motion stops. Within 3% of 1/2.",
+    "\ud83d\udccc The tell was visible BEFORE the withdrawal and neither of us weighed it",
+    "properly: the human, watching both, said the animation itself looks correct.",
+    "A port running 1.0x against a real 0.514x would be twice too fast and they",
+    "would have said so. Their 'looks right' was evidence against the number and it",
+    "was recorded as a puzzle instead of as a measurement. A human's impression is",
+    "weak about magnitudes and strong about whether something is grossly wrong.",
     "",
-    "This SUPERSEDES their earlier 0.463, which divided by the end of MOTION; the",
-    "declared track is stationary from t=540 to t=600, so that denominator was short.",
+    "\ud83d\udfe1 start_units 40 is KEPT but is not settled. Two independent captures agree in",
+    "RATIO form -- the sweep begins 0.798 and 0.791 'baselines' before the plate",
+    "appears, 0.9% apart -- and ratios need no clock, which is what makes them",
+    "survive the withdrawal above. Converting that ratio into title units needs the",
+    "title's own rate, and that is \ud83d\udfe1: in one capture ptcopyright's 22-unit ramp",
+    "reads 1.0 units/frame while the plate's 12-unit ramp reads 0.571, a factor of",
+    "1.75. Until that is resolved the offset is directionally right and numerically",
+    "provisional.",
     "",
-    "CORROBORATION from a second, independent direction: the human, watching both,",
-    "reported the port looks FASTER than the game -- offered as an impression, not a",
-    "judgement to lean on. A 1.0x port against a 0.514x game is exactly twice too",
-    "fast, which is the direction and roughly the size they describe.",
-    "",
-    "RESIDUAL RISK, stated: the rate rests on a SINGLE wrap in a single capture.",
-    "A wrap-to-wrap period would harden it. Adopted anyway because the port's",
-    "current value is not a measurement at all -- it is the unexamined assumption",
-    "that the leaf shares the screen's clock, which this refutes."
+    "Kept rather than reverted because the port's alternative is not a measurement",
+    "either: 0 offset is the unexamined assumption that the leaf shares the screen's",
+    "clock, and every measurement so far says it does not."
   ]
 }