Phase 4: a run record names the machine, not the toolchain

Phase 4: a run record names the machine, not the toolchain

A finished attempt now says which operating system and architecture ran it,
in record.md beside the exit code and the signer, so the two fields ride the
signature that is the attestation. A result a clone carries says what kind
of machine produced it, not only which job it was — which is what turns
"one macOS runner in a Linux pool" into a question somebody can answer
after the fact, and the first half of the targeting work that remains.

The roadmap also asked for the runner's Go version and that was dropped
deliberately: runtime.Version() names the toolchain the *runner binary* was
compiled with, which is not the Go that builds anything in a job. A step
running `go build` uses whatever is on PATH in the checkout, usually a
different install, so in a signed record the field would be a confident
answer to a question nobody asked. OS and architecture survive the same
objection because they describe the machine, which is the fact this was for.

The keys are optional and an absent machine writes nothing at all rather
than an empty line, because a record is never rewritten and history that
predates a field has to stay readable. runs.db mirrors the pair the way it
mirrors the log and the artifacts — only while the runner still holds the
lease, so an overtaken runner leaves no claim behind — and `vole index
rebuild` restores it from the branch.

Measured: TestRunRecordIsPortable carries the machine through the record,
the row, the rebuild and the page; TestRecordWithoutMachineStillReads and
TestMachineIsRecordedOnlyWhileTheLeaseIsHeld pin the two edges.