re: the forced-backdrop rule's pixel cost -- 38 screens go black without it

Follows the necessity census. 'The order moves' is a property of the sort; the
tie-break work already found reorders costing zero pixels, so the picture
moving is a separate claim. Rendered each of the 62 deciding builds twice and
diffed.

  38 .prm deciders: changed_px == ink_px in ALL 38. Without the rule the
                    primitive sorts last, paints over everything, and the
                    screen composites to pure black. The port's original
                    contradiction argument, measured on 38 builds across seven
                    archives instead of argued on two.
  24 .tbm deciders: zero -- and that is MY INSTRUMENT, not a finding.

The control asked whether the composite had ink; it always does. The question
was whether the reordered ELEMENT has ink, and compose draws no pixels at all
for a .tbm. So those 24 zeros measure our renderer's blindness by construction.
tie_break_pixel_cost.rs already had the per-element ink_mask this needed.
Reported rather than quietly patched: a control that cannot fail is the shape
this corpus keeps paying for.

Also corrects two things the port agent caught:

  - 'Two renderers, same answer' was true of the six GP_TITLE instances and not
    of the other 74. The port's re-run of my probe is my code executed twice;
    its independent leg was removing its own exporter post-pass, which covers
    GP_TITLE only. The disc-wide 62 has one witness and the page now says so.
  - forced_backdrop_necessity.rs defaulted to GP_TITLE with no argument, so a
    bare run printed 6 instances in the same format as 80. It now walks every
    dat/*.pak and reports the archive count.

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

docs/re/structures/ui-forced-backdrop.md

@@ -262,8 +262,71 @@ load-bearing on them in the full sense.
 On the five menu screens the exposure is **two**: `GP_TITLE` entries **12 and 15**,
 the dressed loading bundles, where `pgloading_eff00.prm` has neither a read nor an
 implied key. Entries 10, 11, 13 and 14 — the four splashes — are unchanged with the
-rule removed, exactly as the port measured on its own side. Two renderers, same
-answer.
+rule removed.
+
+### The cost in pixels: 38 of the 62 turn the screen black without it
+
+"The order moves" is a property of the sort. The tie-break work already found
+overlapping reorders costing **zero** pixels, so it does not follow that the picture
+moves. Each of the 62 deciding builds was therefore rendered twice — once in
+`derived_paint_order`, once with the fallback removed — and diffed
+([`../data/forced-backdrop-pixel-cost.txt`](../data/forced-backdrop-pixel-cost.txt),
+instrument `examples/forced_backdrop_pixel_cost.rs`).
+
+The split is perfect, and it falls exactly along the element kind:
+
+| | builds | changed pixels |
+|---|---|---|
+| `.prm` deciders | **38** | **0.69 % … 94.41 %** of the frame |
+| `.tbm` deciders | 24 | **0** — but see below |
+
+**On all 38 `.prm` builds, `changed_px` equals the composite's total ink exactly.**
+Not approximately — identically, 38 times out of 38. Without the rule the primitive
+sorts last, paints over everything, and the screen composites to **pure black**.
+That is the port's original contradiction argument, and it is now measured on 38
+builds across seven archives rather than argued on two.
+
+For the port's two: `GP_TITLE` entries 12 and 15 each move **49 771 px = 5.40 %** of
+the frame, which is their entire ink.
+
+### 🔴 The zero on the 24 `.tbm` builds is my instrument, not a finding
+
+**The control I wrote was the wrong control and it passed anyway.** It asked
+whether the *composite* had ink — it always does, the rest of the screen draws —
+when the question is whether *the element being reordered* has ink. This page
+already records that `compose` draws **no pixels at all** for a `.tbm`, because it
+has no resolvable sprite. So a `.tbm`'s paint position cannot change a pixel in our
+renderer **by construction**, and those 24 zeros measure that and nothing else.
+
+`tie_break_pixel_cost.rs` got this right and has the per-element `ink_mask` this
+one needed. Reported rather than quietly patched, because the shape — a control
+that cannot fail — is the one this corpus keeps paying for.
+
+⚠️ So the `.tbm` half of the necessity result stands where it stood: **"correct or
+inert", indistinguishable**, and no closer to being distinguished than before.
+The 38 `.prm` are the part this measurement moves.
+
+### 🔴 "Two renderers, same answer" was true of six instances, not eighty
+
+That sentence stood here and it overstated the evidence. **The port agent caught it
+and it is worth stating precisely, because the failure it guards against is the one
+that started this whole thread** — `verify-screen` scoring two blank frames `OK`.
+
+| | witnesses |
+|---|---|
+| the six `GP_TITLE` instances | **two, genuinely independent** — the port removed *its own* post-pass in its exporter and diffed its export; different code, different language, different layer. My crate-side run agrees |
+| the other **74** | **one measurement, executed twice.** The port re-ran *this crate's* probe. A fault in the instrument reproduces identically for both of us |
+
+So the disc-wide 62 is **not** independently confirmed and this page will not claim
+it is. What the port's re-run does establish is that the probe is deterministic and
+that I transcribed its output correctly — worth having, and much less than
+agreement.
+
+⚠️ **And the instrument had a real trap.** `forced_backdrop_necessity.rs` defaulted
+to `GP_TITLE` when given no argument, so a bare run printed **6 instances in the
+same format as 80**. The port hit it and nearly filed the discrepancy back at me. It
+now walks every `dat/*.pak` by default and reports the archive count on stderr.
+"I ran your instrument" has to mean the same thing to both of us.
 
 ## Reach