re(ui): put a number on the render-vs-capture tone difference

Closes an observation I left dangling last iteration ("the capture is ~4x
darker than the render") and puts a figure on the ❔ INDEX's texture row
already carried: exact gamma/sRGB fidelity untested because a hue
comparison cannot see it.

Geometry first: cross-correlating the main-menu capture against our
render over +/-6 px puts the best alignment at exactly dy=0 dx=0,
correlation 0.9466. Only the tone differs.

Two methods failed before one worked, and both failures are recorded.
Three dark patches gave "4x darker" -- the whole-frame best linear scale
is 0.914, so three patches from one region are not a transfer curve. A
pixel-wise fit over 854,685 pixels then produced a NON-MONOTONIC transfer
(render 96-127 mapping brighter than render 128-159) with mean abs error
10-14 for every candidate model. That is edge misalignment, not a tone
curve: at correlation 0.947 a bright pixel routinely lands on a dark one.

Flat patches fix it -- 16x16 blocks with std < 8 in BOTH images, a
threshold chosen from the counts (0/83/404/1055/1788 at std<3/5/8/12/20):

  main menu  404 patches  gamma 1.491  err 0.28   (best linear 0.276, 0.34)
  EXTRAS     382 patches  gamma 1.493  err 0.22   (best linear 0.273, 0.28)
  title      506 patches  gamma 1.338  err 1.08   (best linear 0.842, 9.02)

Reach, stated because it is narrow: those patches span only render values
~0-60, where gamma and a plain scale are nearly indistinguishable -- the
two menus decide nothing (0.28 vs 0.34, 0.22 vs 0.28) and only the title
separates them. Nothing constrains midtones or highlights.

The held-out control FAILED TO DISCRIMINATE and is reported as such: the
splash's 2918 flat patches are pure black (render 0-4), so every model
scores ~0.00. That is a test with no power, not corroboration.

Confound left open: this compares our composite to what canary DISPLAYS,
and canary applies kernel_display_gamma_type = 2 (BT.709). The exponent
may be its output stage. The discriminating run -- set it to 0, recapture,
refit -- needs one emulator session reaching the main menu and was not
done.

Classified measured, not decoded; HANDOFF says plainly that a port
applying it is authoring.

docs/re/METHOD.md

@@ -482,3 +482,17 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
   lookup by declared name misses. Before concluding a texture is absent, look at
   the bytes the link actually points at — the name in the declaration table and
   the name the sprite table keys on can differ.
+* **A fit whose residual is large for every model is a broken method, not a
+  close call.** Comparing our composite to a capture pixel-wise gave mean abs
+  errors of 10–14 for gamma, for a linear scale, for everything — and a
+  non-monotonic transfer curve (render 96–127 mapping *brighter* than render
+  128–159). The cause was edge misalignment: at correlation 0.947 a bright pixel
+  in one image routinely lands on a dark one in the other. Restricting to patches
+  that are flat in **both** images dropped the residual to 0.2–1.1. When every
+  candidate model fits badly, stop choosing between them and look at what the
+  comparison is actually measuring.
+* **Say when a control failed to discriminate, rather than reporting it as a
+  pass.** The held-out screen for a tone-curve fit was the developer splash,
+  whose flat regions are pure black — every model scored ≈ 0.00 error there. That
+  is not corroboration; it is a test with no power, and reporting the 0.00 as
+  agreement would have dressed an untested claim as a verified one.