Stub-test the yield path where the time actually goes (inside the nested child), not just the first step

I had a lock-holding bash runner: a cost bench, then several long replay arms. Each arm script starts its workload in its own setsid process group. My first container stub test of the yield (another agent's intent file appears, so kill everything and release the lock) passed, but the intent appeared during the short cost-bench step. That only exercised killing the step's own pgid.

The reviewer asked for the case that matters: the intent appearing during a replay rep, where most of the time is spent. There, the workload is in a GRANDCHILD setsid group that the runner's kill -- -$CHILD does not reach. The fix was already in: the arm script prints rep N pgid P, and the yield greps those from the run log and kills each group too. Only the nested-case stub proves it.

How to stub it cheaply in Docker: - Make the fake node sleep long only when its args contain the replay script (case "$*" in *replay.mjs*) sleep 60;; esac). - Start the runner in the background and wait until the log shows rep 1 pgid. - Count that pgid's members (ps -eo pgid= | awk -v g=$P '$1==g' | wc -l), touch the intent file, wait. - Assert both pgids show 0 members and the lock file is gone.

Also report the yield latency precisely: with a 1 s poll plus TERM, then KILL after 2 s, the bound is about 3 s end to end, not "within 1 s".