re: forced_backdrop DECIDES 62 of its 80 instances, not 6

The port agent raised that every check this corpus ran on the rule measured
its STABILITY -- that no verdict moved -- and never its NECESSITY. It is
right, and the distinction is load-bearing.

New probe: recompute derived_paint_order with the forced_backdrop fallback
removed and diff the orders, over every dat/*.pak.

  80 forced instances = 62 the rule DECIDES + 18 it merely AGREES with.

The 80 reproduces the page's own census exactly, which is the check that the
probe sees the same set. Every one of the 62 deciders is keyless; no keyed
element is ever moved.

Of the 18 that agree, 14 have their own key -- and that includes the
palogo_eff0.prm 'control', whose implied key is 0x00000000 and would sort it
first regardless. So that agreement is the rule reproducing our crate, not the
game confirming the rule. The port saw this before I did. The remaining 4 are
keyless but inert: every element on those two builds is forced, so the
tie-break gives the same order either way.

Confirms the port's GP_TITLE finding from the other side: entries 10/11/13/14
unchanged without the rule, entries 12/15 decided by it.

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

@@ -190,6 +190,81 @@ claim with the same consequence. Distinguishing them needs a capture of a screen
 that carries one, which is behind the Ⓐ fault
 ([`ui-clock-freezes-at-settle.md`](ui-clock-freezes-at-settle.md)).
 
+## 🔴 Stability is not necessity — 62 of the 80 are DECIDED by this rule (2026-08-30)
+
+**Raised by the port agent, and it is right.** Every check this page has run — and
+every re-check after a change elsewhere — measured whether a verdict *moved*. That
+is the rule's **stability**. It never measured its **necessity**: an element whose
+position is already fixed by a read `T8aD` key or an `implied_layer_key` is
+*confirmed* by the rule, not *decided* by it, and on those screens removing the
+rule entirely costs nothing.
+
+So the question was asked directly. `derived_paint_order` was recomputed with the
+`forced_backdrop` fallback removed and the two orders compared, over every
+`dat/*.pak`:
+
+| | instances |
+|---|---|
+| the rule **DECIDES** the order — it moves without it | **62** |
+| the rule merely **AGREES** — order unchanged | 18 |
+| **total forced** | **80** |
+
+The 80 reproduces this page's own census exactly, which is the check that the probe
+is looking at the same set. Data:
+[`../data/forced-backdrop-necessity.txt`](../data/forced-backdrop-necessity.txt) ·
+instrument: `crates/sylpheed-formats/examples/forced_backdrop_necessity.rs`.
+
+**Every one of the 62 deciders is keyless — no keyed element is ever moved.** That
+is the rule behaving as designed: it is a fallback, and it only ever fires where
+nothing else can speak.
+
+The 18 that merely agree split two ways, and the distinction matters:
+
+* **14 have a key of their own** — `pfbase.tbm` (10) and `palogo_eff0.prm` (4). Here
+  the sort already had the answer and the rule reproduces it. ⚠️ **This is the part
+  that is not independent support.** `palogo_eff0.prm` being forced first agrees
+  with its measured order, but its `implied_layer_key` is `0x00000000` and would
+  have put it first anyway — so that agreement is the rule reproducing the crate,
+  not the game confirming the rule.
+* **4 are keyless but inert** — `po_menu_base.tbm`, twice in each of two 2-element
+  builds. *Every* element on those screens is forced, so all keys collapse to the
+  same value and the declaration-index tie-break gives the identical order either
+  way.
+
+### What actually holds the 62 up
+
+Not a key — there is none — and not the `palogo_eff0.prm` control, which as above
+is only decisive under a convention its own key already satisfies. **It is the
+impossibility argument alone**: a full-screen quad that is opaque at some instant
+cannot paint above everything visible then, or the screen is blank at that instant.
+That argument is doing all the work on 62 instances, and its assumptions are
+exactly the ones listed under *Reach* below — which is now a larger exposure than
+this page previously implied.
+
+By element, the 62:
+
+| | count | kind |
+|---|---|---|
+| `pzeff00.prm` | 32 | `.prm`, colour census says pure black |
+| `pgloading_eff00.prm` | 4 | `.prm` — 2 in `GP_TITLE` (entries 12/15), 2 in `GP_SAVE_LOAD` |
+| `esrb_base.prm` | 2 | `.prm` |
+| ten `*base*.tbm` families | 24 | `.tbm`, ❔ pixels never located |
+
+⚠️ **24 of the 62 are `.tbm`**, and this page already records that a `.tbm`'s
+pixels cannot be found anywhere on the disc. For those the two readings — "the rule
+places it correctly" and "the element draws nothing, so its position is inert" —
+remain indistinguishable, and both leave the composite right. The 38 `.prm`
+deciders have no such escape: those are real quads with real colour, and the rule is
+load-bearing on them in the full sense.
+
+### For the port specifically
+
+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.
+
 ## Reach
 
 ⚠️ **Assumes straight alpha-over blending.** Blend mode is ❔ on