re: full suite green, and correcting the route I recommended last

iteration

Two loose ends, both on my own work.

The disc-gated suite finally completed: all six binaries, 131 passed,
0 failed, one pre-existing ignored. So the rest() fix and the T8adImage
flags field are fully verified rather than verified-on-three-binaries.
The reason earlier attempts produced empty logs was that the tool
timeout's SIGTERM reached the whole process group; setsid nohup survives
it, which is now a METHOD line.

And a correction that matters more. Last iteration I closed the swoosh as
undecodable from the disc and named a per-draw GPU capture as the next
route, "because it reads the actual blend state". It does not. Reading
command_processor.cc, each captured draw records primitive type, index
count, index-buffer address, VS and PS ucode hashes, the pixel shader's
texture bindings, and vertex attribute 0 of binding 0. There is no
RB_BLENDCONTROL dump.

So the route splits, and I have said so rather than leaving the wrong
version standing: the capture can test a per-draw VERTEX COLOUR today
with no code change, which would explain white-versus-pink directly, and
getting the blend mode itself needs a Canary change to dump the blend
registers. Either way it is instrumentation rather than another field.

The general lesson goes in METHOD too: validate a recommendation before
leaving it as advice. A named next step is a claim like any other, and I
made it without checking.

docs/re/METHOD.md

@@ -299,3 +299,14 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
   literals, so `cargo test` failed to compile with exit 101. A green build on the
   binary is not a gate for a struct change; run the tests before believing a
   data-structure edit is safe.
+* **Detach long background work with `setsid`, or a tool-call timeout kills it.**
+  Three attempts to run the disc-gated test suite in the background died at exit
+  143 with an empty log — the timeout's SIGTERM reached the whole process group.
+  `setsid nohup cargo test … &` survives, and the run then completes across later
+  tool calls. An empty log from a "background" job usually means it was killed,
+  not that it produced nothing.
+* **Validate a recommendation before leaving it as advice.** Having concluded a
+  question was undecodable from the disc, I named a per-draw GPU capture as the
+  next route "because it reads the blend state". It does not — checking the
+  capture's own source showed it records textures and vertex attributes and no
+  blend registers. A named next step is a claim like any other.