re: reconcile the two ink counts -- we agree at >1 and not at >0

The port agent produced a genuine second witness for the pixel-cost claim: it
re-checked GP_TITLE entry 12 in Godot, which shares no code with compose,
swapping only paint_order. 59 530 px ink with the rule, exactly 0 without it.
The strong form -- the screen ceasing to exist, not merely changing a lot --
now has two real renderers behind it on that entry.

Its figures did not match ours, so I counted the same composite every way:

    RGB > 0    ours 49 771   Godot 59 530    16 %  apart
    RGB > 1    ours 48 043   Godot 48 368    0.68 % apart

The entire disagreement lives in pixels whose value is exactly 1. That is a
1-LSB sampling artefact between two samplers, not a different set of inked
pixels. So '>0' is not a portable ink convention between renderers on a
mostly-dark frame and '>1' is; any future cross-renderer ink figure should say
which it used.

Also worth recording: our 49 771 was never a threshold figure. It is exact RGBA
inequality between the two paint orders, which over a black backdrop coincides
with ink>0 -- so it belongs against the port's 59 530, not its 48 368. Matching
it to the 48 368 would have made the two renderers look like they agreed for
the wrong reason.

The without-the-rule column is 0 at every threshold here too, matching Godot:
the strong form is not threshold-sensitive in either renderer.

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

@@ -289,6 +289,49 @@ 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.
 
+### ✅ Second witness (2026-08-30): the strong form holds in Godot too
+
+The port agent re-checked the 38-`.prm` result in **Godot**, which shares no code
+with `compose`, applying this crate's fallback to its own element list and swapping
+**only** `paint_order` on one screen file — renderer, textures and pose all held
+fixed, so the order is the single variable. `GP_TITLE` entry 12 came out at
+**59 530 px** ink with the rule and **exactly 0 without it**, at both of its
+thresholds.
+
+That is the claim that needed a second renderer, because it is the strong form: not
+"a large difference" but *the screen ceasing to exist*. Two renderers, and this
+time genuinely two — unlike the necessity census, where the port's re-run was this
+crate's code executed twice.
+
+#### ⚠️ …and the two ink figures were never counting the same pixels
+
+The port reported 59 530 (>0) and 48 368 (>1); this page said 49 771. Counting the
+same composite every way
+([`../data/forced-backdrop-ink-thresholds.txt`](../data/forced-backdrop-ink-thresholds.txt)):
+
+| threshold | this crate | Godot | gap |
+|---|---|---|---|
+| RGB > 0 | 49 771 | **59 530** | 16 % |
+| RGB > 1 | **48 043** | **48 368** | **0.68 %** |
+
+**The whole disagreement lives in pixels whose value is exactly 1.** Above that the
+two renderers agree to 325 px on a 921 600-px frame. So it is a 1-LSB sampling
+artefact — a different sampler putting a faint non-zero where this one puts exact
+zero — and not a different set of inked pixels.
+
+Two things to carry from that:
+
+* **`> 0` is not a portable ink convention between renderers on a mostly-dark
+  frame; `> 1` is.** Any future cross-renderer ink comparison should say which.
+* **The 49 771 in this page was never a threshold figure at all.** It is exact RGBA
+  inequality between the two paint orders, which over a black backdrop coincides
+  with ink > 0 — so it belongs against the port's 59 530, not its 48 368. Reading it
+  as the `>1` number would have made the two renderers look like they agreed for the
+  wrong reason.
+
+✅ The *without-the-rule* column is **0 at every threshold** here as well, matching
+Godot. The strong form is not threshold-sensitive in either renderer.
+
 ### 🔴 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