Record a job that never started as could-not-run, not as a failure

Record a job that never started as could-not-run, not as a failure

A run that never executed a step was recorded exit=1, steps=nil, and the run page
said the same thing it says when a test fails. With checks required on a protected
branch, a runner that could not build an image red-flagged a commit whose tests
pass, and the only way back was a rerun by hand.

Two facts were collapsed into one: the job ran and something failed, which is the
repository's problem, and the job never ran, which is the machine's. The runner
knows the difference exactly once, and it does not need to guess whose fault it
was: if no step ran, nothing about the commit was tested.

- A record can now say where it stopped: Failure=setup means the attempt ended
  before the job's first step, with the runner's own one-line reason in
  FailureMessage, masked the way the log is. The reason is what the page shows
  instead of making a reader open the log to learn the machine broke.
- A run whose newest attempt has that origin is StatusError, which the pages call
  "could not run". It is not StatusFailed: it is not evidence against the commit.
- The gate reads it as a wait, not a refusal. Landing stays blocked because nothing
  is verified, but the commit is not blamed, and the gap names the reason and the
  rerun command.
- The run list counts and filters it, the run page explains it, and the change list
  says "CI could not run" rather than "CI failed".

A step that exits non-zero is still a failure and still reds the check, because
that one is the code's. `vole runner` still reports a setup failure with exit 1;
the origin is what carries the meaning, so an old runner and an old instance keep
talking.

Not done here, on purpose: a run whose attempts all vanished before reporting (the
lease-loss exhaustion in RequeueExpired) still ends as failed. That run has no
record to say what ran, and a job that repeatedly kills its runner is not
distinguishable from a machine problem from the queue's side; issue #243 is where
that gets a signal. Nor is a setup failure requeued automatically: MaxAttempts is
about flaky tests, not broken runners, and #247 already stops a runner whose
runtime cannot start a container from serving at all. A rerun is a button.

The finish path now takes an attemptOutcome instead of six positional arguments,
which is also what lets a failure after the last step keep the steps that ran
instead of dropping them.

Closes 01M6Z05K5PM58EE3H6VE2P2EYD