port: F6 -- adopt the sweep onset as a measured RATIO, and fix the guard that disabled it

Onset: 0.500 of (title first visible element -> plate onset), measured by the
Decoder as 0.489 and 0.507 across two independent captures, 3.7% apart. A RATIO,
which is the point -- it needs no clock, and every unit-valued figure from those
captures has been withdrawn: the rate because frames are presents (1168 vs 600
for the same animation), the '+40 units' because its conversion put
title-start->plate at 75 units where the declared data puts the plate at 238, a
3.2x conflict that is still open and is F4's.

Resolved against THIS export: 0.500 x (214 - 0) = 107.0 units.
tools/port/check-leaf-onset recomputes it and fails if a re-timing moves the
anchors; it has a selftest in both directions and is in check-all.

🔴 AND THE ADOPTION WAS A NO-OP UNTIL THIS COMMIT. leaf_clock() read
'if start < 0.0 OR rate <= 0.0: return screen_units', so when the withdrawn rate
went back to null the adopted OFFSET stopped applying too -- silently, while
authored/rendering.json still stated it. The two fields are independent now.

It was caught only because the offset was re-verified by PROBING THE RENDERER
instead of re-reading the file I had just edited. Both my earlier verifications
of this feature passed while it did nothing: one compared frames that were all
being forced to the same pose, the other ran when both fields happened to be set.

Verified, pre-registered before running, via --probe-leaf:
  title u=236 -> leaf_t 129.0, x -123   (predicted 129, -123)
  title u=400 -> leaf_t 293.0, x  533   (predicted 293,  533)

Effect: at the plate's arrival the sweep sits at x=-123, just entering the frame,
where before it was at x=305, well across it.

authored/rendering.json

@@ -171,38 +171,41 @@
   ],
   "leaf_clock": {
     "title": {
-      "start_units": 40.0,
-      "rate": null
+      "start_units": 107.0,
+      "rate": null,
+      "start_fraction": 0.5,
+      "fraction_from": "title first visible element (t=0)",
+      "fraction_to": "press_start ptbtn00 onset (t=214)"
     }
   },
   "leaf_clock_why": [
-    "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.",
+    "leaf_t = screen_t - start_units. rate is null = the leaf runs at the screen's",
+    "rate; nobody has a clock-free measurement of a rate and the one attempt was",
+    "withdrawn (below).",
     "",
-    "\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 107 = 0.500 x (214 - 0), resolved HERE from this export's own",
+    "declared keyframes. The 0.500 is the measurement; the 107 is arithmetic on it.",
     "",
-    "\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.",
+    "MEASURED as a RATIO, which is the point: (onset - title start) / (plate - title",
+    "start) = 0.489 and 0.507 across two independent captures, 3.7% apart",
+    "(Decoder, docs/re/f6-unit9-sweep-period-and-onset.md + 15670f4). A ratio needs",
+    "no clock, which is why it survived when every unit-valued number did not.",
     "",
-    "\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.",
+    "\ud83d\udd34 EVERY TITLE-UNIT FIGURE FROM THE CAPTURES IS WITHDRAWN, twice over:",
+    "  - rate 0.514 units/frame: captured frames are PRESENTS and the present rate",
+    "    differs per run -- 1168 frames vs 600 for the same animation, 1.947x.",
+    "  - offset '+40 units': converted through the plate's declared 12-unit ramp,",
+    "    a calibration that puts title-start->plate at 75 units where the declared",
+    "    data puts the plate at 238. That is a 3.2x clock conflict, still open, and",
+    "    it is F4's `clock: shared` question.",
+    "Both were adopted here and both were reverted before shipping.",
     "",
-    "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."
+    "\ud83d\udccc The human said the animation LOOKS correct while we were carrying a rate",
+    "that would have made it twice too fast. That was evidence against the number",
+    "and both agents filed it as a puzzle. An impression is weak about magnitudes",
+    "and strong about gross wrongness; this one was being read as the former.",
+    "",
+    "\u26a0\ufe0f 107 is arithmetic on THIS export's keyframes. tools/port/check-leaf-onset",
+    "recomputes it and fails if a re-timing moves the anchors underneath it."
   ]
 }