port: the loading screens are black at EVERY instant, which disproves my layer rule

build_12 and build_15 have rendered blank since P3 and I had filed it as a rest()
casualty. It is not, and the corrected keyframe association makes it provable.

pgloading_eff00, a 1280x720 black quad, is opaque alpha 255 from t=0 to t=38 and
clears at t=48. Every other element on the screen peaks between t=8 and t=32 and
is gone by t=32-40. So the quad covers the entire span in which any content is
up, and clears only after everything else has faded. Rendered with the timeline
PLAYING at t = 20, 30, 36, 40, 42, 44, 46 and 50 units, the frame is mean 0 at
every one.

That is not a bad choice of pose. Under the port's current layer rule there is no
instant at which this screen shows anything, and a loading screen that is black
for its whole life is not what the game does -- a proof by contradiction rather
than a preference.

THE RULE UNDER SUSPICION IS MINE AND IT IS NARROW. pgloading_eff00 carries
layer_source "none" and the exporter sorts a layerless element LAST, on top.
Every other full-frame primitive in the export has a layer key (main_menu, extras
and title all give pteff00 0x00008030), so this only ever bites here -- which is
why it survived eight milestones behind two screens nobody draws.

Where a layerless element sorts is a DECODE and I have not answered it. If the
game sorts it first, behind everything, the screen renders and the quad becomes a
backdrop, which is consistent with the contradiction but not established. Asked
rather than flipped.

It does settle that verify-screen's BLANK verdict on those rows was right:
sylpheed-cli agrees with the port there precisely because it shares the
assumption under suspicion.

Also recorded: the Decoder has withdrawn "the game never draws eff3" -- it draws
all five -- and the mechanism is the one my developer-splash refutation caught a
layer down. A draw batches several quads and the log dumps only the first 8
vertices, so min/max merges them; eff3 lies entirely inside eff4 so the union is
exactly eff4's extent. My 525x259 was gamearts_eff merged with seta_eff the same
way. Nothing in the port changes: eff3 was never dropped and the splash still
draws three sprites.

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

docs/port/DECISIONS.md

@@ -4821,3 +4821,76 @@ that number is the *denominator* of the units-per-frame conversion behind the
 9-unit black hold I just authored, so an error in it would have propagated
 straight into a constant I ship. Two derivations from different sides of the same
 record agreeing to 0.02 % is what makes that constant safe to hold.
+
+## 🔴 The loading screens are black at *every* instant — which proves the layer rule wrong for a layerless element
+
+`build_12` and `build_15` have rendered blank since P3, and I had filed it as a
+`rest()` casualty: `pgloading_eff00` is a 1280×720 quad whose `rest` is opaque
+black. **It is not that**, and the corrected keyframe association makes it
+provable rather than suspected.
+
+Every element's declared alpha window on `build_12`:
+
+| element | opaque / visible | gone by |
+|---|---|---|
+| **`pgloading_eff00`** (black quad) | **t=0 … 38 at alpha 255** | clears at t=48 |
+| `pgloading_loop4` | t=8…32 | 38 |
+| `pgloading_loop1` | t=16…32 | 40 |
+| `pgloading_line` | t=18…26 | 32 |
+| `pgloading_str` | t=22…28 | 34 |
+| `pgloading_loop3` | t=24…26 | 34 |
+| `baseeff`, `eff01`, `eff02`, `loop5` | t≈16…32 | 32–40 |
+
+**The quad is fully opaque across the entire span in which any content is up, and
+it only clears at t=48 — by which time every other element has faded to zero.**
+Rendered at t = 20, 30, 36, 40, 42, 44, 46, 50 units with the timeline *playing*,
+the frame is **mean 0 at every one**.
+
+So this is not a bad choice of pose. **Under the port's current layer rule there
+is no instant at which this screen shows anything**, and a loading screen that is
+black for its whole life is not what the game does. That is a proof by
+contradiction, not a preference.
+
+### The rule under suspicion is mine, and it is narrow
+
+`pgloading_eff00` carries `layer_source: "none"` — no layer key at all — and the
+exporter sorts a layerless element **last**, i.e. on top. Its `paint_order` is
+`[6, 7, 8, 9, 1, 5, 4, 2, 3, 0]` with element 0, the quad, drawn last.
+
+⚠️ **Every other full-frame primitive in the export has a layer key** —
+`main_menu`, `extras` and `title` all give their `pteff00` `0x00008030` — so this
+rule only ever bites here, which is exactly why it survived eight milestones
+behind two screens nobody draws.
+
+❔ **Where a layerless element sorts is a decoding question and I am not
+answering it.** If the game sorts it *first* — behind everything — the screen
+renders and the quad becomes a backdrop rather than a cover, which is what a
+1280×720 black rectangle at the bottom of a loading screen would sensibly be.
+That reading is *consistent* with the contradiction above, which is not the same
+as being established, and I have asked rather than flipped the sort.
+
+✅ **What this does settle:** `verify-screen`'s `BLANK` verdict on those two rows
+was the right call. It reports that both renderers drew nothing and that the row
+proves nothing — and `sylpheed-cli` agrees with the port here precisely because
+it shares the assumption under suspicion. Two renderers agreeing, again.
+
+## Their `eff3` retraction — my refusal was right, and my refutation found the same bug
+
+The Decoder has withdrawn *"the game never draws `eff3`"*. It draws all five, in
+the declared stagger, in both title entries. **And the mechanism was the one my
+developer-splash refutation had already caught one layer down**: a draw batches
+several quads and the log dumps only the first 8 vertices, so min/max over a
+line's vertex list *merges* them. `eff3` (788…1196) lies entirely inside `eff4`
+(447…1196), so the union is exactly `eff4`'s extent and `eff3` vanished with
+nothing anomalous to see. My `525×259` was `gamearts_eff` merged with `seta_eff`
+by the identical mechanism.
+
+⚠️ **The part worth carrying is theirs**: three explanations were reported "ruled
+out", and all three were aimed at the wrong failure — the *"a draw the log cannot
+see"* check counted draws with **no** geometry when the hiding place was draws
+with **partial** geometry. **Refuting three wrong hypotheses is not evidence for
+a fourth**, and a list of failure modes written by whoever built the instrument
+is the least likely to contain that instrument's blind spot.
+
+Nothing in the port changes: `eff3` was never dropped, and the developer splash
+still draws three sprites.