docs: the suite is heavy, not hung -- correcting my own "cannot terminate"

Last iteration I wrote that build-reborn test cannot finish in a working
session, from having watched it run 3h26m. That was the stronger claim
and I made it without measuring the work.

Timing `mesh info` on each of the 166 .xpr containers with a 25 s cap:

  files scanned                166
  exceeding 25 s                19   Hangar, 17 Stage_*, ptc_pack
  Stage_S02 to completion      144 s, rc = 0

Nothing hangs. Nineteen heavy containers at roughly two minutes each is
about 45-60 minutes for one pass, before the 147 fast ones. The 3h26m
observed was that hour of work running at a load average of 9-14 --
inflated by the two duplicate runs I had left going, which did not merely
coexist with the slowness but multiplied it.

The practical conclusion is unchanged and only the wording softens: an
hour-scale suite is not an iteration-scale gate, and every "green" I
reported from it this session was partial. But an hour-scale gate can be
run deliberately, whereas a hung one cannot be run at all, so the
distinction is worth having right.

File list committed as reference data so the cost is attributable without
re-scanning.

METHOD: a slow thing observed under contention looks like a stuck thing;
measure the work before choosing between "cannot finish" and "takes an
hour".

docs/re/METHOD.md

@@ -734,3 +734,11 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
   suite is stated to have terminated — so report the suite count and elapsed
   state rather than the word "green", which is what I should have been doing all
   session.
+* **"Cannot finish" and "takes an hour" are different claims — measure before
+  choosing.** I wrote that the verification gate *cannot terminate*, from having
+  watched it run 3 h 26 m. Timing the work directly: 19 of 166 containers exceed
+  25 s, `Stage_S02` completes in **144 s**, and one full pass is ~45–60 minutes.
+  Nothing hangs. The 3 h 26 m was that hour of work at a load average of 9–14,
+  inflated by my own duplicate runs. A slow thing observed under contention looks
+  like a stuck thing, and the correction matters: an hour-scale gate can be run
+  deliberately, a hung one cannot be run at all.

docs/re/REFUTED.md

@@ -516,3 +516,9 @@ neighbourhood, not just the line.
   flagged group violates it on a median **52.5 %** of pixels against **30.2 %**
   unflagged — both far from premultiplied, and the flagged group *further*.
   [`ui-paint-order-key.md`](structures/ui-paint-order-key.md)
+* "`build-reborn test` cannot terminate" → **mine, and too strong; corrected the
+  next iteration.** It is heavy, not hung: 19 of 166 `.xpr` containers exceed
+  25 s, `Stage_S02` completes in **144 s** with `rc = 0`, and one full pass is
+  ~45–60 minutes. The 3 h 26 m observed was that work at a load average of 9–14,
+  inflated by my own two duplicate runs.
+  [`test-suite-runtime.md`](test-suite-runtime.md)

docs/re/data/slow-xpr-files.txt

@@ -0,0 +1,22 @@
+# .xpr files whose `mesh info` decode exceeds 25 s (debug build), of 166 scanned
+# 2026-08-29. Stage_S02 measured at 144 s to completion, rc=0 -- heavy, not hung.
+
+Hangar.xpr
+Stage_S02.xpr
+Stage_S03.xpr
+Stage_S04.xpr
+Stage_S06.xpr
+Stage_S07.xpr
+Stage_S08.xpr
+Stage_S09.xpr
+Stage_S11.xpr
+Stage_S12.xpr
+Stage_S13.xpr
+Stage_S15.xpr
+Stage_S24.xpr
+Stage_S25.xpr
+Stage_S26.xpr
+Stage_S27.xpr
+Stage_S28.xpr
+Stage_S29.xpr
+ptc_pack.xpr

docs/re/test-suite-runtime.md

@@ -1,4 +1,4 @@
-# 🔴 `build-reborn test` cannot finish in a working session — and I left two runaways
+# 🟡 `build-reborn test` takes about an hour — and I left two runaways
 
 **Status:** ✅ measured. Two facts, one of them my own mess.
 
@@ -16,6 +16,27 @@ fn twin_pairs_do_not_share_a_buffer() {
 ```
 
 Measured: one instance accumulated **3 h 26 m of CPU at 89 %** without finishing.
+
+### 🔴 "Cannot terminate" was too strong — corrected
+
+It terminates; it is merely heavy, and I said the stronger thing before measuring
+it. Timing `sylpheed-cli mesh info` on each of the 166 files with a 25 s cap
+([`data/slow-xpr-files.txt`](data/slow-xpr-files.txt)):
+
+| | |
+|---|---|
+| files scanned | 166 |
+| exceeding 25 s | **19** — `Hangar`, 17 `Stage_*`, `ptc_pack` |
+| `Stage_S02` timed to completion | **144 s**, `rc = 0` |
+
+So nothing hangs. Nineteen heavy containers at roughly two minutes each is
+**~45–60 minutes** for one pass, before the 147 fast ones. The observed 3 h 26 m
+was that work running at a **load average of 9–14** — inflated by my own two
+duplicate runs competing with each other and with this one. The runaways did not
+merely coexist with the slowness; they multiplied it.
+
+⚠️ The practical conclusion is unchanged and only the wording softens: an
+hour-scale suite is not an iteration-scale gate.
 Its sibling in the same file, `shared_resources_decode_identically_in_every_container`,
 walks the same 166 files and *is* `#[ignore]`d (as known-failing), so the binary's
 cost is easy to underestimate from a glance at the file.