The fifth aspect of #2338, and the one none of the others can reach.

The gap

#2323, #2327, #2333, #2335 and #2336 are all changes inside one gate run. None
of them composes across runs, because no in-repo configuration can observe
another session's gate:

• Four worktrees at maxWorkers: 4 (Vitest worker count is a library default that oversubscribes this team's machines #2336) is still 16 workers on 8 logical
  cores — worse than one session at the current default.
• A budget raised for a 2x-oversubscribed machine (Test-gate timeouts are still library defaults — the unit, tui and launcher projects and all 788 Testing Library waits fail correct tests under concurrent-worktree load #2323) is the wrong number for
  a 6x-oversubscribed one, and no single committed value is right for both.

That is not an argument against those issues. It is the statement that they
optimize a single session's footprint, while the thing that actually varies is
how many sessions are running, which is precisely the working mode #2338
exists to support: three or four concurrent agent sessions, each in its own
worktree, each free to run the full gate.

Evidence that it is the dominant term

From #2323's survey, during ordinary parallel work on an 8-logical-core machine:

load averages: 60.41 68.40 56.68
load averages: 49.70 61.86 55.40

6x to 8.5x oversubscription, sustained — four worktrees, 27 node
processes, 9 matching vitest|eslint. Nothing in vitest.shared.mts can see any
of that.

Sampling during a single gate on an otherwise quiet machine puts steady
background at 1.5–2 cores and shows the spikes coming from the gate itself, so
one session already saturates the box. The multi-session case is not a small
multiple of a solved problem; it is the unsolved one.

The shape of a fix

An advisory lease on local:gate: a run takes a lock, and a second run
either waits for it or proceeds at reduced parallelism. Cross-process, so a
lockfile under a well-known path rather than anything in-repo — core/'s
existing proper-lockfile usage (#2082) is prior art in this codebase for
cross-process locking done carefully, including stale-holder takeover.

⚠️ One trap to design around, recorded in #2323 and worth restating because it
is easy to build by accident: two sessions each running a naive "wait until
the machine is clear" loop deadlock on each other — neither ever clears,
because each is the reason the other is waiting. A lease has to grant, not poll
a threshold.

Questions a design needs to answer, none of which has an obvious default:

1. Queue or degrade? Waiting is simple and makes the second session slow to
   report. Degrading (fewer workers) keeps both moving and makes neither run's
   timing comparable to a solo run — which matters, because Make the test gate trustworthy on a machine running several agents at once #2338's whole method
   is measuring against a baseline.
2. What is the lease unit? The whole local:gate, or only its parallel
   stages? Its serial stages (lint, build, the smokes) do not contend the same
   way.
3. How does a crashed holder release? Stale-lock takeover, with the
   FileSecretStore has no cross-process mutual exclusion: decide whether to adopt an OS-backed lock #2082 caution that a takeover window shorter than a refresh interval declares
   live holders dead.
4. Opt-in or default? A lease that surprises someone by blocking their gate
   for ten minutes will be disabled within a day.
5. Is it worth it at all versus simply telling people to run fewer sessions?
   ⚠️ Test-gate timeouts are still library defaults — the unit, tui and launcher projects and all 788 Testing Library waits fail correct tests under concurrent-worktree load #2323 rules that out explicitly — "per-developer advice is out of scope:
   parallel worktrees are the intended working mode here" — so answering "just
   don't do that" needs to reopen that decision rather than assume it.

Not in scope

• Anything that makes CI slower. GitHub runners are not contended this way and
  went 8 for 8 green through PR fix: state every test-gate timeout instead of inheriting a library default #2334; a lease should be local-only or no-op
  when CI is set.
• Weakening any gate. This is about when work runs, never about what is
  checked.
• retry. See Make the test gate trustworthy on a machine running several agents at once #2338's non-goals.

Acceptance

• A design decision is recorded on this issue for each of the five questions
  above — including "not worth building", if that is the answer, with the
  reasoning.
• If built: two sessions starting local:gate within seconds of each other both
  complete green, and neither blocks indefinitely when the other is killed
  mid-run.
• The Make the test gate trustworthy on a machine running several agents at once #2338 acceptance it unblocks is measured: a local:gate run on this
  machine, with two other sessions running their own gate concurrently, is
  green.