docs: the verification gate cannot terminate, and I left two runs going 4h

Two findings from checking whether last iteration's partial green had
finished. It had not, and the reason matters for anyone using the gate.

build-reborn test contains twin_pairs_do_not_share_a_buffer, which
decodes every .xpr in hidden/resource3d -- 166 files, 1.4 GB -- through
the full Xbg7Model anchoring path, and is NOT #[ignore]d. Its sibling in
the same file walks the same 166 files and IS ignored as known-failing,
which makes the binary's cost easy to underestimate. Measured: one
instance accumulated 3h26m of CPU at 89% without finishing.

So every "green run" reported in this corpus from a workspace or
sylpheed-formats test is necessarily PARTIAL unless it says the suite
terminated -- including the ones I reported this session. The honest form
is the suite count and elapsed state, not the word "green". Not proposing
to #[ignore] or subsample it: that changes what the suite asserts and is
the project's call, not an audit side-effect.

And the mess is mine. Two cargo test -p sylpheed-formats runs launched
detached in earlier iterations never exited, because they were sitting in
that test:

  pid 103375  4h12m elapsed  child mesh_consistency_disc  3h26m CPU  89.3%
  pid  99965  4h39m elapsed  child pak_idxd_disc          1h16m CPU  93.8%

Load average 14.18 on 12 cores. Killed, after checking the legitimately
running workspace suite and leaving it alone; load fell to 9.68.

What this does NOT explain, because it is tempting: the session's
emulator troubles. screenshot cost 0.49 s with both runaways live and the
emulator stopped, against 10.8 s measured earlier with the emulator
running. The 92x figure really was emulator contention; the runaways were
a background tax on top. The black surface and the unreachable title
stand as measured, with their own controls.

METHOD: a detached job you never check can outlive many iterations --
setsid was added so a timeout could not kill them, which also means
nothing does; and know whether your verification gate can terminate.

docs/re/METHOD.md

@@ -721,3 +721,16 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
   version grepped for the doc's formatting (`14 709` with a thin space, `33.7`
   rounded from `33.66`) and reported almost every figure as a mismatch. A
   consistency check that fails on formatting will train you to ignore it.
+* **A detached job you never check can outlive many iterations.** Two
+  `setsid nohup cargo test … &` runs from earlier iterations were still alive
+  **four hours** later, one child at 89 % CPU for 3 h 26 m, holding the load
+  average at 14 on 12 cores. `setsid` was added precisely so a tool-call timeout
+  could not kill them — which also means nothing kills them. Check that a
+  backgrounded run actually exited before launching the next one, and prefer
+  `ps -o etime=` over assuming.
+* **Know whether your verification gate can terminate.** `build-reborn test`
+  includes a disc test that decodes 166 `.xpr` files (1.4 GB) and had not
+  finished after 3 h 26 m of CPU. Every "green run" from it is partial unless 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.

docs/re/test-suite-runtime.md

@@ -0,0 +1,57 @@
+# 🔴 `build-reborn test` cannot finish in a working session — and I left two runaways
+
+**Status:** ✅ measured. Two facts, one of them my own mess.
+
+## The gate the brief names does not complete
+
+`build-reborn test` (`cargo test --workspace` with `SYLPHEED_DISC` wired up) is
+the verification gate. It contains a disc test that decodes **every `.xpr` in
+`hidden/resource3d` — 166 files, 1.4 GB** — through the full `Xbg7Model`
+anchoring path:
+
+```rust
+#[test]                                   // NOT #[ignore]d
+fn twin_pairs_do_not_share_a_buffer() {
+    …for f in &files { … Xbg7Model::anchor_models_cancellable(&bytes, 0.0, &|| false) … }
+```
+
+Measured: one instance accumulated **3 h 26 m of CPU at 89 %** without finishing.
+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.
+
+⚠️ **Consequence for anyone using this gate:** every "green run" reported in this
+corpus from a workspace test is necessarily **partial** unless it explicitly says
+the suite terminated. `cargo test -p sylpheed-formats` reaches ~131 tests in a few
+minutes and then sits in this one; the workspace run is the same picture. Quote
+the suite count and the elapsed state, not the word "green".
+
+🟡 Not proposed here: `#[ignore]`-ing it, or bounding it to a sample of the 166.
+Both change what the suite asserts, which is the project's call and not a
+side-effect of an audit.
+
+## 🔴 And I left two of them running for four hours
+
+Two `cargo test -p sylpheed-formats` runs launched detached in earlier iterations
+never exited, because they were sitting in this test. At the moment they were
+found:
+
+| pid | elapsed | child | CPU time | %CPU |
+|---|---|---|---|---|
+| 103375 | 4 h 12 m | `mesh_consistency_disc` | **3 h 26 m** | 89.3 |
+| 99965 | 4 h 39 m | `pak_idxd_disc` | 1 h 16 m | 93.8 |
+
+Load average **14.18** on 12 cores. Killed; load fell to **9.68** within a
+minute, and the legitimately-running workspace suite was checked first and left
+alone.
+
+### 🔴 What this does NOT explain
+
+It is tempting to pin the session's emulator troubles on this, and the
+measurement says no. `screenshot` cost **0.49 s** with both runaways live and the
+emulator stopped, against the **10.8 s** measured earlier with the emulator
+running. So the 92× figure in
+[capture-harness-status](capture-harness-status.md) really was emulator
+contention, and the runaways were a background tax on top — not the cause. The
+black surface and the unreachable title stand as measured, with their own
+controls.