Phase 4: a new tip cancels the old build, and the lease serves the quiet repo

Phase 4: a new tip cancels the old build, and the lease serves the quiet repo

Two ways a single repository could monopolise the instance's runner pool. A push
series queued a build per commit, so ten pushes in a minute ran ten builds of nine
dead commits — `StatusCanceled` existed, the gate knew how to report it, and nothing
ever wrote it. And the lease ordered by age across every eligible repository, so the
oldest job won wherever it lived: one busy repository's queue was served before a
quiet repository's, no matter how many runners were busy with the first.

Cancellation is now decided where the workflow's own trigger is decided: a push that
owes at least one run retires the *queued* runs of that repo+ref whose sha it
replaces, and nothing else — a running job is never interrupted, since a build
canceled mid-flight is a different promise from one nobody started, and a push that
queues nothing (no matching workflow) cancels nothing. The count is logged, because a
run that stops for no findable reason reads exactly like a run that vanished.

The lease orders by in-flight count per repository first and age within a repository
second, which needs no new config key and no operator tuning: the burst still runs,
it just cannot occupy every runner while another repository waits.

Measured: TestCancelSupersededOnlyTouchesWaitingRunsOfTheSameRef (1 canceled, another
ref untouched, the running job still running), TestLeaseServesTheLeastBusyRepoFirst
(the busy repository's older second job is passed over for the quiet repository), and
TestANewerTipCancelsTheQueuedBuildOfTheOlderOne end to end through the reconciler.

Canceled runs are queue state, not history — they never happened, so they have no
record and `vole index rebuild` drops them rather than inventing one.