runner: -jobs N runs that many builds at once !241

Stacked on !240.

N workers running the loop that was in main. ClaimBuild has always been a single transaction that selects and updates, and each build already works in its own build-<id> directory, so several workers were safe the whole time — the runner just never used more than one. -once still means one build; idle polls are staggered so N workers do not wake together.

TestRunnerConcurrentJobs asserts overlap from the runner's own log — a build started before the first finished — rather than from wall clock, which also covers N concurrent clones and made a fast machine look serial in my first attempt. Pinning the runner back to one worker fails it.

Scope: this is the -jobs N half of #115 only. The image: half is now #144, because the issue's own wording gates it on "once isolation exists" and choosing between a container runtime, bwrap, or a per-build user plus mount namespace is a decision with a bay1 deployment attached, not a code change. #144 also records what a build can currently reach, which matters more now that -jobs N puts several side by side under one workdir.

Closes #115