Phase 4: one repository may be bounded, and a freed slot wakes the parked

Phase 4: one repository may be bounded, and a freed slot wakes the parked

max_jobs_per_repo caps how many of one repository's jobs run at once; unset
there is still no cap. Ordering and bounding answer different questions: the
lease already serves the least busy repository first, which stops a burst
taking the whole fleet, but ordering is not a bound — and what an operator
wants when one repository's build saturates the instance is a number.

A repository at its cap is skipped rather than blocking, so the other
repositories an account may run are still served. That makes nil from the
lease mean two things: "nothing to do", and "work exists, but not for you
yet". The second meaning is why Finish now wakes the parked lease — releasing
a slot is work somebody can pick up, and without it a runner parked on a cap
would sit out its whole wait against a queue it could already have taken.
Both are one line of the same query: `? = 0 OR COALESCE(busy.n, 0) < ?`, so
"no cap" does not become a second query string that can drift.

The runners page renders `4 of 4 (at the cap)` beside the depth, because a
queue that is full and not draining is exactly the question that page exists
to answer: "7 waiting, 4 running" is a mystery where the cap is not shown.

Measured: TestPerRepoCapBoundsOneRepositoryAndResumesWhenASlotFrees puts two
jobs in each of two repositories with a cap of 1, so "nothing to lease"
cannot be confused with "no work" — both repositories served once, a third
runner refused, a finish waking the parked lease and the freed slot's own
repository becoming leasable. TestRunnersPageSaysWhenARepositoryIsAtItsCap
and TestMaxJobsPerRepoLoads cover the page and the key.