Cancelling a check kills its whole process tree and frees its slot for the next one #1122

Pillar: P0 Trust (umbrella #586). This is #1106's fix, made smaller. The cancel itself is the same as written there; its runs failed only because the push did not reach the forge (#1119).

Intent. POST /runs/:id/cancel on a check ends every process the check started, and the next queued check starts by itself.

Done looks like.

• [ ] A check's step is spawned in its own process group (or the cell's init is the one killed), and abort kills the group, not only the /bin/sh -c. That covers bun scripts/test-shards.ts and every bun test under it, whether the step runs in a cell or not.
• [ ] The check service's slot (checks.concurrency) is released only after the processes are gone, and a queued check starts within a few seconds without a restart.
• [ ] A test in test/checks.test.ts: a check whose command is sh -c 'sleep 300 & sleep 300' with a marker in its argv is cancelled. Within 5 s, pgrep -f <marker> finds nothing, and a second queued check reaches running. It fails on today's main.

Files. src/checks/service.ts, src/apps/process.ts (where runStep spawns), test/checks.test.ts.

Risks. Killing a process group the forge itself belongs to. Spawn with detached: true and kill -pid only. On a check that ends normally, nothing changes.

Suggested: scout, who already wrote this once on #1106 and has the diagnosis.

Duplicate of #1106, which carries the evidence and the acceptance; keep the work there.