5981d106

By: Tom Sydney Kerckhove <syd@cs-syd.eu>

Let a failed control name the test that killed it

A control is a no-op mutation, so it cannot legitimately be killed: a killed
control means the suite is flaky or the harness is buggy, and it fails the run.
But the report said only that one had failed, never which test killed it, and
report.json carried nothing but a count. Survivors and timeouts each get their
child's output; a failed control got none.

The cause was one hardcoded Nothing. A child that exits non-zero is a kill and
its output was discarded, which is right for the thousand-odd ordinary
mutations of a healthy run, whose kill is expected and whose output says
nothing. For a control the kill is the finding, so this dropped the evidence at
exactly the moment it mattered.

SuiteKilled now carries an optional log path, and the driver keeps the log only
when the killed mutation is a control, under a control-failure- prefix. So the
report gains one file per control failure rather than one per mutation, and the
failed-control section points at it.

Found while chasing a control that failed once in nix-ci, at a time-based wait
computation, with no way to tell which test did it and no way to reproduce it
outside a loaded mutation run.