port: F6 FOUND -- the gate was declared data the renderer was discarding

The sweep starts early because ScreenView drew a leaf WITHOUT multiplying its
parent's alpha in. ptloop01/ptloop02 declare 0:0 70:0 100:255 238:255 250:0, so
the sweep is invisible until t=70 and full at t=100. The port has had that ramp
in its export the whole time and was throwing it away at the draw call.

Three changes:

1. Parent alpha multiplies into the leaf's. This file asserted the opposite,
   arguing from the sweeps being drawn while their parent had expired -- but that
   could not separate 'the leaf wins' from 'the parent is ignored because it
   draws nothing', and its own comment said so and named the interval that would
   settle it. Measured there: dividing the leaf's declared curve out of the drawn
   alpha pins the implied parent at 255.0 (+/-1.5) over hundreds of frames while
   the drawn alpha swings 242 -> 132 -> 145.

2. rate 0.5, calibrated against a DECLARED interval (ptloop01's own 30-unit ramp)
   rather than captured frames: two runs differing 2x in frames give 0.4795 and
   0.4667, 2.7% apart. This number was 0.514, withdrawn, now reinstated at 0.5 --
   what failed the first time was quoting a rate in presents, and the ratio was
   discarded along with the frames.

3. The 107-unit authored offset is DELETED, with its guard tool. It came from a
   ratio measured against an element identified only by screen position; the
   declared ramp needs no such identification. Deleting an authored value because
   the data already says it is the outcome PORT-MISSION asks for.

Also reverted, same day I made it: removing the transparent-parent skip. I read
'the game submits the sweep ~950 frames past its parent's expiry' as the leaf
outliving the parent. It does not follow -- a draw submitted at alpha 0 is still
a draw, and submitted is not visible. With the multiply, skipping on a
transparent parent IS multiplying by zero.

VERIFIED, pre-registered before running, via --probe-leaf:
  u= 60 -> no draw at all           (predicted: parent alpha 0.00, gated off)
  u=100 -> leaf_t 50.0,  x -439     (predicted 50.0, -439)
  u=236 -> leaf_t 118.0, x -167     (predicted 118.0, -167)
verify-capture: every row unchanged.

⚠️ BUILD-SENSITIVE: builds 5 and 6 of GP_TITLE declare these records as a single
flat a=255 with no ramp. This export reads the ramped build; if that changes the
gate disappears silently.

authored/rendering.json

@@ -171,41 +171,40 @@
   ],
   "leaf_clock": {
     "title": {
-      "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)"
+      "start_units": null,
+      "rate": 0.5
     }
   },
   "leaf_clock_why": [
-    "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).",
+    "leaf_t = rate * screen_t. A null field means 'not measured'.",
     "",
-    "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.",
+    "rate 0.5 -- the leaf's clock runs at HALF the screen's.",
+    "  Measured by the Decoder against a DECLARED calibration rather than captured",
+    "  frame counts: using ptloop01's own declared 30-unit alpha ramp (t=70..100) as",
+    "  an in-capture title clock, two runs whose frame counts differ 2x give",
+    "  leaf/title = 0.4795 and 0.4667, 2.7% apart.",
+    "  docs/re/f6-unit10-parent-alpha-gates-the-sweep.md.",
     "",
-    "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\udd34 This number was adopted as 0.514, withdrawn, and reinstated as 0.5 within",
+    "  one day. What failed the first time was quoting a rate in captured FRAMES --",
+    "  frames are presents and the present rate differs per run (1168 vs 600 for one",
+    "  animation). The ratio itself was sound; it was discarded with the frames.",
+    "  A calibration that is itself declared does not have that failure mode.",
     "",
-    "\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.",
+    "start_units null -- there is NO authored onset any more, and that is the point.",
+    "  F6's gate is DECLARED: ptloop01/ptloop02 carry `0:0 70:0 100:255 238:255",
+    "  250:0`, so the sweep is invisible until t=70 and full at t=100. The port had",
+    "  that ramp in its export the whole time and was discarding it, because",
+    "  ScreenView drew the leaf without multiplying the parent's alpha in.",
     "",
-    "\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.",
+    "  A 107-unit offset was authored here earlier, from a measured 0.50 ratio. It",
+    "  is retired: the ratio was measured against an element identified only by",
+    "  screen position, and the declared ramp needs no such identification. Deleting",
+    "  an authored value because the data already says it is the better outcome.",
     "",
-    "\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."
+    "\u26a0\ufe0f BUILD-SENSITIVE. Builds 5 and 6 of GP_TITLE declare these same two records",
+    "as a single flat a=255 keyframe -- no ramp, hence no gate. This export reads",
+    "the ramped build (verified: 0:0 70:0 100:255 238:255 250:0). If that ever",
+    "changes the gate silently disappears."
   ]
 }