PausedSelector_SeededDroppedServerReady_RecoversOnIdleSweep kept failing on the
Linux runner even after its wall-clock patience was widened to 60 s — the
assembly ran 1 m 39 s and recovery still never completed, so this is real
starvation of the session's background threads, not a tight timeout.
Measured on the runner itself:
default parallelism FAILED in 40 s
MaxParallelThreads=1 PASSED in 10 s
Serial is both correct and four times faster there, because the contention was
also costing wall-clock. Scoped to this one project on Linux: Windows has 18
cores, passes with default parallelism in ~7 s, and serializing this assembly
for everyone previously REGRESSED it (1000 passed in 7 s -> 999/1000 in 17 s).
Replaces the earlier '-- xUnit.MaxParallelThreads=2' that was applied to every
Linux project: too weak to help and too broad to be safe.