ci: run tests in parallel on hosted runners (the required lane was forced serial everywhere)

[dieterolson]

ci: run the test suite in parallel on hosted runners (it was forced serial everywhere)

tests (3.11) is one of two required checks and it has been timing out. Raising
its cap from 90 to 150 minutes (#4539) did NOT help — the next run consumed
150.3 minutes. That ruled out "slightly too slow" and pointed at the real cause.

Per-step timings from the cancelled job on PR #4525 (a four-file, formatting-only
change whose reformat was proven AST-identical):

step 23 Run Tests with Coverage (Python 3.11) 147.5 min CANCELLED
everything else combined ~4 min

So the test step is effectively the whole job, and it runs with -n 0 — fully
serial. That override is unconditional, and its stated reason is specific to one
runner class: "the memory-constrained local runner fleet has repeatedly crashed
xdist workers even at low fan-out".

That reason does not hold on a hosted runner. The failing job ran on
GitHub Actions 1000355575 — 4 vCPU / 16 GB, not memory-constrained. And the
timings across recent runs line up exactly with runner class rather than with any
code change:

77.7 min SUCCESS d-sorg-local-Oglaptop-1 (fleet hardware, fast cores)
150.3 min CANCELLED hosted (slower per-core, same serial run)
93.5 min CANCELLED d-sorg-local-Desktop-3
91.2 min CANCELLED d-sorg-local-Desktop-6

Forcing serial execution onto slower hosted cores is what pushes the job past any
cap. So the fan-out is now chosen per runner class instead of globally:

PYTEST_FANOUT: ${{ needs.pick-runner.outputs.runner == 'd-sorg-fleet' && '0' || 'auto' }}
pytest_args+=(-n "${PYTEST_FANOUT:-0}")

Fleet hosts keep -n 0, so the crash this override was written to prevent is
still prevented. Hosted runners get -n auto (4 workers), which should take the
test step from ~148 minutes to roughly 40.

Two details that make this safer than it looks:

• --dist loadscope comes from the repo's own addopts and is unchanged, so a
  module's tests stay on one worker. That matters because the Qt tests use 15
  second waitUntil timeouts and are load-sensitive; loadscope keeps them from
  being split across workers.
• The default is 0, not auto (${PYTEST_FANOUT:-0}). If the variable is ever
  unset the behaviour is today's serial run, so this fails safe.

This follows the conditional the tests job already uses for PIP_CACHE_DIR,
which switches on the same needs.pick-runner.outputs.runner == 'd-sorg-fleet'
test.

The 150-minute cap from #4539 is left in place as headroom rather than reverted;
with parallelism it should be far from binding. If it stops being needed it is a
one-line revert.

Verified: scripts/validate_workflows.py, scripts/check_workflow_pinning.py
and scripts/check_blocking_quality_gates.py all pass; the tests job still
parses to 27 steps; and the env var is on the tests job and NOT on
quality-gate (both jobs carry an identical PIP_DEFAULT_TIMEOUT: "120" line,
so a first-match patch lands in the wrong job — worth knowing when editing this
file).

Part of #4532

Co-Authored-By: Claude Opus 5 noreply@anthropic.com

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.