port: HOLD the parent-alpha adoption -- the two sweep sprites are the same size

The Decoder's bound refutes screen_view.gd's 'parent alpha NOT multiplied in'.
Premise verified here: pteff03's leaf floors at 128, so a drawn alpha below that
cannot come from the leaf alone.

But the identification is 'by size', and pteff03 and pteff03a are BOTH 399x180 --
consistent with the two reported rows measuring 1.38x3.15 and 1.39x3.15. Size
separates the sweeps from the screen, not from each other.

That flips the cited row: pteff03a's leaf floors at 0 and ramps 0->128 over
t=0..150, so 8/24/33/50 is exactly that leaf alone. The conclusion may still hold
via the OTHER row (16 with a 128-131 cluster is pteff03's signature) -- the
finding may be right and the cited row wrong.

Free discriminator already in their capture: the leaves travel in OPPOSITE
directions, ~1000 px apart. Renderer unchanged until the row is identified.

docs/port/f6-what-starts-the-sweep.md

@@ -104,3 +104,61 @@ by one authored value. Nothing else moves.
 * It does not touch the glow. A boot looks exactly as it did.
 * It says nothing about whether the *speed* or the *path* is right — only when it
   begins.
+
+---
+
+# 🔴 Unit b, HELD: the parent-alpha refutation may be right, but its identification step cannot carry it
+
+**Status:** ⏸️ **the renderer is NOT changed.** The Decoder's
+`f6-unit2-parent-alpha-multiplies.md` refutes `screen_view.gd`'s *"the parent's
+alpha is NOT multiplied in"* using a bound. The bound's shape is sound and its
+premise checks out against this export. **The step that assigns the measurement
+to an element does not.**
+
+## The premise holds
+
+`pteff03`'s leaf declares `0:255 150:128 540:255 600:255` — **minimum 128**,
+confirmed off `export/screens/title/title.json`. A drawn alpha below 128 cannot
+come from that leaf alone. That part is right.
+
+## 🔴 But the two strips are the SAME SIZE, so size cannot say which is which
+
+The identification is stated as *"by size against the corpus's independently
+measured AABB height of 1134 px"*. Measured off this export:
+
+| sprite | dimensions | leaf alpha range | travel |
+|---|---|---|---|
+| `pteff03` | **399 × 180** | **128 … 255** | left → right (−639 → 1521) |
+| `pteff03a` | **399 × 180** | **0 … 255** | right → left (1721 → −839) |
+
+**They are byte-identical in size**, which is consistent with the two reported
+rows measuring `1.38 × 3.15` and `1.39 × 3.15` — a 0.7 % difference. Size
+separates the sweeps from everything else on the screen; it cannot separate them
+from **each other**, and that is the distinction the argument needs.
+
+## Why it matters — the assignment flips the conclusion
+
+The quoted row that reaches **8** is the one the argument leans on. But
+`pteff03a`'s leaf alpha floors at **0**, not 128, and ramps `0 → 128` across
+t=0…150. Values of 8, 24, 33, 50 … are exactly what **that leaf alone** produces.
+So if the 8-row is `pteff03a`, the bound is satisfied with no parent at all.
+
+⚠️ **And the conclusion may still be correct via the OTHER row.** The row
+reported as `16 41 67 91 116 128 129 130 131` contains values below 128 *and* a
+dense cluster at 128–131 — the signature of `pteff03`'s floor. If that row is
+`pteff03`, then 16 < 128 refutes no-multiply exactly as claimed. **The finding
+may be right and the cited row wrong.**
+
+## The discriminator is free and already in their capture
+
+The two leaves travel in **opposite directions**: `pteff03` left→right,
+`pteff03a` right→left, separated by ~1 000 px for most of their run. One frame
+pair settles it. Nothing needs re-capturing.
+
+## What the port does about it: nothing yet
+
+Adopting a decode whose element assignment is unresolved is how this project has
+been burned before — and the port would be changing a renderer rule on it.
+`screen_view.gd` keeps its current behaviour until the row is identified by
+travel direction. **This is not scepticism about the conclusion**, which the
+port's own flagged limit predicted would fall this way; it is about which row.