Spec run default parallelism oversubscribes small machines #201

This was generated by AI during triage.

A Spec run's default parallelism (3 Tickets at once), plus any Runs started by hand, easily oversubscribes a small machine. Each Run's agent session builds and tests in its own worktree, so three concurrent sessions mean three cargo test/clippy jobs competing for the same cores.

Evidence (2026-09-30, 4-core / 8GB VM, no swap):

• Load average 24–27 with 3 Merge runs and a Spec run's Tickets going. /proc/pressure/cpu showed some avg300=97%, and sys time was 26% from process spawning.
• A full cargo test that takes minutes on a quiet machine took 15–16 minutes, past the 600s Bash timeout sessions run under (see Make the test suite faster #174, Sessions wait on a backgrounded command by its own task, not by process name #180).
• About 2.8GB of memory was available with no swap. Each claude process uses about 200–350MB, and a rustc or linker peak can take 0.5–1GB, so one more parallel link risks the OOM killer rather than just slowing down.
• The claude processes themselves cost almost no CPU. Runs waiting on the model or on CI are cheap, and the cost is in their local builds and tests.

To decide:

• Should a Spec run's default parallelism come from the machine (e.g. cores / 2, capped by available memory) instead of a fixed 3? parallel <n> and spec.parallel would still override it.
• Should thirdshift warn, or hold back starting a Ticket, when the machine is already saturated (CPU pressure, available memory)?
• Is anything needed for Runs started by hand in separate terminals, which don't know about each other, or is that left to the user?
• thirdshift is language-neutral, so any build-level limit (e.g. CARGO_BUILD_JOBS) would be the repo's or the user's to set, not thirdshift's.