On a 1-CPU forge a look waits while a crew run is working, and is taken after it ends #11724

On a 1-CPU forge the looks service now takes no look while a crew run is active. The waiting look is taken on the first sweep after the run ends.

• The hold: in src/looks/service.ts, the drain loop checks crewHoldsCore(cpus(), activeCrewRuns()) before each look. When it is true, the look goes back to the front of the queue, so its place is kept, and the loop stops. Every sweep now restarts the loop first, so a held look is picked up once the run is gone. src/looks/capture.ts and its Gate(1) are untouched.
• Injection: LooksOptions gains cpus and activeCrewRuns. They default to forgeCpus() and listActive(db, "agent").length.
• Tests: the new test/looks-one-core.test.ts covers three cases. With 1 CPU and an active run, two sweeps take no look. When the run ends, the next sweep takes it. With 2 CPUs and an active run, the look is taken at once. The 1-CPU test fails with service.ts stashed. The 2-CPU test passes without the change, as expected, since it checks the hold doesn't apply with two cores. It uses a real production deploy and a fake capture, so it needs no chromium and no crew loop.
• Allow-list: I removed src/core/one_core.ts from scripts/unreached-allow.json.

bun x tsc --noEmit is clean and test/looks-one-core.test.ts passes in the sandbox. bun scripts/gate.ts printed no output, and I didn't check its exit code.

test/looks.test.ts has 3 failures in the sandbox because the real chromium can't start here (socket() failed: Operation not permitted). They fail the same way on the base commit, and I edited no existing tests.

I didn't touch checks or snapshots.

Closes #11598

On a 1-CPU forge the looks service now takes no look while a crew run is active. The waiting look is taken on the first sweep after the run ends.

• The hold: in src/looks/service.ts, the drain loop checks crewHoldsCore(cpus(), activeCrewRuns()) before each look. When it is true, the look goes back to the front of the queue, so its place is kept, and the loop stops. Every sweep now restarts the loop first, so a held look is picked up once the run is gone. src/looks/capture.ts and its Gate(1) are untouched.
• Injection: LooksOptions gains cpus and activeCrewRuns. They default to forgeCpus() and listActive(db, "agent").length.
• Tests: the new test/looks-one-core.test.ts covers three cases. With 1 CPU and an active run, two sweeps take no look. When the run ends, the next sweep takes it. With 2 CPUs and an active run, the look is taken at once. The 1-CPU test fails with service.ts stashed. The 2-CPU test passes without the change, as expected, since it checks the hold doesn't apply with two cores. It uses a real production deploy and a fake capture, so it needs no chromium and no crew loop.
• Allow-list: I removed src/core/one_core.ts from scripts/unreached-allow.json.

bun x tsc --noEmit is clean and test/looks-one-core.test.ts passes in the sandbox. bun scripts/gate.ts printed no output, and I didn't check its exit code.

test/looks.test.ts has 3 failures in the sandbox because the real chromium can't start here (socket() failed: Operation not permitted). They fail the same way on the base commit, and I edited no existing tests.

I didn't touch checks or snapshots.

I merged main into the branch and pushed; the only conflict was scripts/unreached-allow.json.

main had dropped src/apps/cpu_rule.ts from the list, and this branch had dropped src/core/one_core.ts. I kept both removals, so the list now holds only page_budget.ts, page_budget_read.ts, pod.ts and qr.ts.

After the merge, bun scripts/gate.ts printed nothing, bun x tsc --noEmit was clean, and test/looks-one-core.test.ts passes (2 tests). I did not re-run test/looks.test.ts after the merge. The forge's check will run the full suite on this push.