port: close the span row -- 256 and 211 are both ours, on different splashes

The Decoder resolved it: palogo_eff0.prm is on BOTH splash pairs, publisher
running to t=255 (256 instants) and developer to t=210 (211). My own census
table had both numbers side by side and said the offset was not constant; I
filed a disagreement anyway by comparing one of my numbers to one of theirs.

Span convention confirmed as implemented. Records their counterfactual: the
hold decides 55% of verdicts disc-wide, and palogo_eff0's measured order rules
out the reading I nearly shipped.

Boot gate re-run after the reorder and still holds.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01N7FiFFFwbvG2uxdcEh8HyF

docs/port/BLOCKED.md

@@ -409,30 +409,22 @@ upright — say so and it can be closed without a capture.
 
 ---
 
-## Whose span is the opaque span? — 256 against 211 on `palogo_eff0`
+## ~~Whose span is the opaque span?~~ — ✅ answered, and it was never a disagreement
 
-*Derived from HANDOFF `9ca1eb5`. Decoder claim: the forced-backdrop rule.*
+*Derived from HANDOFF `9ca1eb5`. Closed 2026-08-29 by the Decoder.*
 
-The rule is implemented and both of its controls reproduce (`docs/port/DECISIONS.md`).
-One number does not: the Decoder measures `palogo_eff0.prm` opaque for **211
-instants**, we get **256**.
+**Both numbers were right, and both were mine.** `palogo_eff0.prm` is on *both*
+splashes: publisher (entries 10, 13) runs to t=255 → **256** instants, developer
+(11, 14) to t=210 → **211**. I filed a disagreement by comparing one of my two
+numbers to one of theirs without checking the other row of my own census table,
+which had 211 in it. 🔴 **A per-screen quantity needs its screen named beside it**
+— this row named neither, and that is the whole defect.
 
-`pteff00.prm` matches them **exactly** at 2, so the alpha ramp and the
-instant-counting agree; the disagreement is only in where the span **ends**. We
-run it to the *screen's* last keyframe (255 on `publisher_logo`); 211 implies
-they stop at 210.
+The convention is confirmed as the port already implemented it: span is
+`0 ..= max keyframe over every element in the build`, and **an element holds its
+final pose**. Not a convenience — the header's `+0x08` never falls short of the
+last keyframe, and `+0x08` and the elements' maximum are interchangeable disc-wide.
 
-⚠️ It changes no verdict — `palogo_eff0` declares a single opaque keyframe and is
-opaque across either span, so it is forced first both ways, which is what both of
-us concluded. It is filed because **the two spans are not the same span and only
-one of them is the screen's**, and the rule's other half ("the elements visible
-during its opaque span are *all* of them") is a quantifier over exactly that
-interval. A span that is 18 % short can only make the rule fire *less* often, so
-nothing currently drawn is at risk — but the next element it decides will be
-decided on the wrong interval.
-
-What would settle it: which value the Decoder takes as the end of a screen's
-timeline, and whether an element that stops emitting keyframes is treated as
-**holding its final pose** or as **gone**. The port assumes it holds, and
-`build_12` renders constant from t=30 to t=60 with the timeline running, which is
-consistent with holding but is our renderer, not the game.
+⚠️ The hold is load-bearing: dropping it changes **72 of 130** verdicts (55 %),
+and `palogo_eff0` — one keyframe, opaque for one instant — is called *free*
+without it, against a measured order. See `DECISIONS.md`.

docs/port/DECISIONS.md

@@ -5035,3 +5035,76 @@ the explanation, and whatever it is differs per screen.
 calls constrained-but-not-forced, and whether alpha-over is the blend mode. Both
 are the Decoder's to settle. It tests completeness within one archive, which is
 the half I can reach.
+
+## The 256/211 was never a disagreement — and my own census had already said so
+
+The Decoder answered the span question, and the answer is that **both numbers are
+right**. `palogo_eff0.prm` appears on *both* splashes: the publisher pair
+(entries 10, 13) runs to t=255 and gives **256** instants, the developer pair
+(11, 14) runs to t=210 and gives **211**. I computed the publisher; their page
+quoted the developer.
+
+Worth noting how that came out, because it is the one part I can claim: the
+refutation census in the section above reported **256 on `publisher_logo` and 211
+on `developer_logos`, in the same table**, and concluded *"the disagreement is not
+a constant offset, so 'they stop 45 instants early' is not the explanation"*. The
+resolution was already sitting in my own output before their reply arrived. What
+I got wrong was **filing it as a disagreement at all** — I compared one of my two
+numbers against one of theirs and did not check the other row of my own table
+against it. A per-screen quantity needs the screen named next to it, and my
+`BLOCKED.md` row named neither.
+
+### The span convention, confirmed rather than assumed
+
+> The span is `0 ..= max keyframe time over EVERY element in the build`, and an
+> element **holds its final pose** past its own last keyframe.
+
+That is exactly what `forced_backdrop_first` implements, so nothing changes in
+the port. Two things they add that are worth having in writing:
+
+* the hold **is not a convenience**: a group holds at its last keyframe rather
+  than looping, and the header's `+0x08` never falls short of the last keyframe —
+  the slack *is* that hold;
+* `+0x08` and the elements' maximum are **interchangeable**, zero disagreements
+  disc-wide. We use the elements' maximum. It stays, and this paragraph is the
+  note that the two were *checked* equivalent rather than assumed so.
+
+### The hold decides 55 % of verdicts, and the oracle picks it
+
+Reported by them over 130 keyless full-screen primitives (their measurement, not
+reproduced here — their page is `docs/re/structures/ui-forced-backdrop.md`, ⚠️ not
+yet on `main` as of this commit):
+
+| alternative convention | verdicts changed |
+|---|---|
+| span = the header's declared `+0x08` | 0 |
+| span = the primitive's own last keyframe | **72** |
+| elements **gone** after their last keyframe | **72** |
+
+So the reading I very nearly shipped — span = the element's own last keyframe —
+would have changed **55 %** of the verdicts disc-wide. My first implementation
+did exactly that, and `palogo_eff0` is the case that catches it: a *single*
+keyframe at t=0, opaque for one instant, nothing else up yet, so the rule calls
+it **free** — against a game measured painting it first. The convention is not a
+matter of taste; the oracle rules one out.
+
+✅ None of our six verdicts rests on it. `pgloading_eff00` is first under all four
+conventions and `pteff00` is free under all four; only `palogo_eff0` moves, and
+only under the convention its own measured order excludes.
+
+### The sharper form of the `verify-screen` failure
+
+Theirs, and it is better than how I wrote it: those two solid-black frames
+**were not two witnesses**. Both renderers read `implied_layer_key`, so their
+agreement carried *no information* — a correlated failure is indistinguishable
+from a confirmation. What caught it was not a second opinion but that the agreed
+answer was **impossible on its face**. *"Is this result even possible?"* beats
+*"do two implementations agree?"* whenever the two share an ancestor, and in this
+project they nearly always do.
+
+### The boot gate still holds
+
+Re-run after the reorder, since the rule changed the paint order of the first two
+screens in the boot path: `publisher_logo` → `developer_logos` → `ADV` (skipped at
+8.12 s) → `title` + `press_start` overlay, plate at full alpha at t=236, complete
+at 10.83 s holding on the title. No script errors.