A vanished suite worker is reported as a clean run

[xroche]

The Windows suite's fork-failure counter reads the console log for the messages bash prints when MSYS fork emulation gives out, so a worker that dies without bash saying anything is invisible to it: run 32484281897 ended on "no MSYS fork failure in suite-console.log" about a leg that had just lost 86_local-proxytrack-cache-longfields.test. The issue's account of the mechanism holds, with one correction: the suite step was not green. The tally already counted a missing .rc as a failure, so the leg exited 1. What was indistinguishable was the class, in the counter's verdict and in the failing: list.

The tally now has three outcomes instead of two. A failed test keeps FAIL and its place in failing:; a worker that left no status gets a LOST verdict saying how far it got (no log, a 0-byte log, or a log its test had written), a lost= field in the tally line, and an ::error:: naming the leg as one to re-run; a clean run says so with the lost count included. The counter reads those LOST lines back and annotates them, so its clean sentence is never printed bare again. A lost worker stays fatal, since a leg that tested less than it reports must not ship green, but exits 3 rather than 1 when nothing else failed: the status is all the workflow keeps of the difference between a leg to repeat and a red to investigate (#1228). The parent's wait status is deliberately not used, because wait -n reaps workers the pool can no longer name; the log the worker opened is what survives.

Classification moved into ci_read_outcome and ci_lost_reason, above the driver's source guard, so 337_ci-lost-worker.test can drive it off the Windows runner: the four .rc states, the counter over a clean, a fork-failure, a lost-worker and a mixed console, a mutant with the LOST rule removed proving the old counter misread the same log as clean, and a driver run over 115 stub tests where one stub kills its own worker, the control leg exiting 0 against the killed leg's 3 with lost=1 and nothing in failing:.

Closes #1352