Make controls sparser and cheaper to run
Stacked on #156, whose `writeChildTask` it does not depend on but whose driver version and changelog it would otherwise collide with. Rebase onto `development` once that merges.
A control is a no-op mutation that is expected to survive, so unlike a real mutation its child cannot stop at the test that kills it: it runs every covering test it is given, to the end. That makes the cheapest kind of mutation to produce the most expensive kind to run.
Measured on nix-ci's `leader`, after #156 removed the per-child manifest parse. Per-child wall over 150 random mutations: median 1.05 s, mean 5.64 s, p99 91 s, max 155 s — and the top 5 of those 150 are 62% of the time:
| covering tests | wall | mutation |
|---|---|---|
| 150 | 155.5 s | `PostJobRequest/Control/169/3/32/42` |
| 178 | 129.8 s | `PostJobRequest/Control/1235/11/12/9` |
| 2 | 91.0 s | `GetSuiteWait/ConstBool/57/12/27/2` |
| 4 | 91.0 s | `GetSuiteWait/IntLit/204/21/24/1` |
| 20 | 55.1 s | `PostJobRequest/Control/484/28/42/47` |
Summing the covering-test baselines over that run's 213 controls, and charging each child's suite setup once rather than once per test, they come to ~6320 of the phase's 16144 slot-seconds at eight jobs: **7% of the mutations, 39% of the phase**.
### What changes
- One control every hundred mutations rather than every twelve (`controlInterval`).
- Each control is checked against its cheapest ten covering tests rather than all of them (`controlCoveringTestLimit`). The cap lives in the coverage phase, so the record says what the child will run and the child's budget is derived from it.
- Every module gets a control at its first mutation site. It did not need one before: at one per twelve, every module of any size got one anyway, and at one per hundred a project of small modules gets none. That also keeps this repository's own example — whose modules are far smaller than a hundred mutations — exercising controls at all; without it the example's goldens lose every control.
On the leader manifest: 213 controls become 46 (15 from the interval, the rest from the per-module floor), each bounded at ten tests instead of up to 934.
### What this trades
Fewer controls and fewer tests per control is less flakiness insurance. What a control is for is noticing a suite that cannot be relied on under the mutation phase's own concurrency, and 46 children running up to ten tests each still sample that; what goes away is re-running the same covering sets dozens of times over. The cap is also why the per-module floor is affordable.
### Tests
`CoverageSpec` is new and covers `annotateRecord` directly: an ordinary mutation keeps every covering test and gets a budget from all of them; a control keeps the cheapest ten and gets a budget from those ten. Each fails without the change. `mutation-manifest-example`'s goldens are refreshed, and the plugin suite and the four example mutation checks pass.