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/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.