On a 1-CPU forge checks and snapshots start only between crew runs; two or more CPUs start them at once #11599

Intent: the last third of #11561. A check or a snapshot never shares the single core with a working crew run.

Done:

• [ ] pickNext (or the loop that calls it) in src/checks/service.ts starts no new check while crewHoldsCore(...) (src/core/one_core.ts) is true. Queued checks keep their order and start when the run ends. A check already running is left alone
• [ ] startSnapshots in src/snapshot/service.ts defers a snapshot due while the crew holds the core, and takes it on the next tick after
• [ ] the CPU count and the active-run count are injectable through each service's options, so tests need no real size, servers or crew loop
• [ ] new test/checks-one-core.test.ts, in-process: 1 CPU with a fake active run holds a queued check and a due snapshot, and both start once the run is gone; 2 CPUs start them at once. Each test fails without the change
• [ ] bun x tsc --noEmit and bun test test/checks-one-core.test.ts pass in the sandbox before the push

Files: src/checks/service.ts, src/snapshot/service.ts, test/checks-one-core.test.ts (new). Risks: the merge gate (gate) must still be able to run, so a red main is never held forever. If holding the gate needs more than these files, hold only pull checks and snapshots, and say so in the pull. No looks, web or docs change. Suggested brief: mason.

Parked by the crew: the check stayed red through 2 automatic tries (pull #11642 closed; its branch scout/11599-on-a-1-cpu-forge-checks-and-snapshots-st at 7cf8b09612e1 keeps the work so far). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.

try 1: scripts/unreached-allow.json, src/checks/service.ts, src/core/one_core.ts, src/snapshot/service.ts, test/checks-one-core.test.ts try 2: src/snapshot/service.ts try 3: AGENTS.md, docs/APPS.md, docs/MCP.md, docs/THREATS.md, docs/design/areas/feed.md, docs/features/growth.md, docs/features/pick-list.md, docs/features/sto…