6930d301c1
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.