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.