tool_scheduling_tests: the concurrency limit check fails when a sleep overruns 150 ms #225

tool_scheduling_tests checks that a tool limited to one run at a time does not keep the other tools waiting (testToolConcurrencyLimit, "the other tools run while the limited tool works through its files"). The check compares stopwatch times.

On a pool of two workers:

• the limited tool takes 200 ms per file, so it is done with its three files after about 600 ms;
• the other tool runs its files on the second worker, 150 ms each, so it is done after about 450 ms;
• the check passes if the other tool is done first.

Every order the pool can take leaves a 150 ms margin. The check therefore fails only when a sleep overruns, or a worker starts late, by more than 150 ms.

GitHub's macOS runners do that now and then.

• Since the check was added on 2026-10-01, it failed 8 times in about 100 macOS attempts: 6 on macos-14 and 2 on macos-15. None of these failures came with a change to the scheduler.
• The last one failed main after docs: record coretrace-stack-analyzer#257 as merged in the contributions log #223, which changed only a document.
• Build on macos-15 is a required check, so each failure blocks a merge until the job is rerun.

Change

Make the check wait instead of measure:

• Each run of the limited tool waits for the other tool to be done with every file, and gives up after 10 s.
  • If it gives up, it throws, and the invoker reports the tool as failed.
• The check becomes: no tool failed.
  • It holds when the other tool runs while the limited tool holds its worker.
  • It fails when the scheduler makes the other tool wait for the limited one.
• The check that the limited tool never runs twice at once stays.

The 10 s limit is still a time bound. It is about 20 times the expected wait of 450 ms, against 150 ms of margin today.

Acceptance

• The check no longer compares end times.
• It still fails when the scheduler makes the other tools wait for the limited tool. This is checked by breaking runOnPool locally.
• On macOS, the current check fails when the test runs at background priority (taskpolicy -b). The new check passes under the same conditions.