Resolve per-test actions concurrently during plan construction

[inju2403]

Motivation

Test execution is already parallel, but plan construction isn't: _constructStepGraph resolves each test's action — running its traits' prepare(for:) and evaluating its test cases — serially, before any test runs. For typical suites that's immaterial, since planning is already sub-millisecond. But when many tests have async-evaluated conditions or traits (for example .enabled(if: await …)), this serial pre-phase runs every async evaluation back-to-back before the first test starts — and because execution is already parallel, that pre-phase can become the dominant cost of the run.

This PR resolves those actions concurrently, so the work that the run phase already parallelizes is no longer serialized one step earlier. It's a no-op for suites without async trait work, and it's distinct from the existing // FIXME in _determineAction (which is about parallelizing a single test's traits; this is the cross-test axis). How common the async-condition regime is in practice is a call I'd defer to you.

Modifications

Gather the non-placeholder tests, resolve each test's action concurrently in a withTaskGroup, then apply the resolved tests and actions back into testGraph/actionGraph. Mutating the shared actionGraph is the only reason the original await testGraph.mapValues { … } loop had to be serial, so that mutation is hoisted out of the concurrent region; everything else is unchanged. Behavior is equivalent to the serial version — the same tests, actions, and graph structure result, and actions are applied serially after collection, so the outcome is independent of completion order. The existing suite passes and swift build succeeds.

• Honors --no-parallel: the serial path is taken when isParallelizationEnabled is false.
• Not throttled by maximumParallelizationWidth (which bounds how many test cases run at once), since this is one-time planning work rather than execution — happy to gate it on the width instead if you'd prefer.
• prepare(for:) and parameterized-argument closures now run concurrently across tests. Traits are Sendable and scope providers already run concurrently during execution, so well-behaved traits are unaffected; the only case this could surprise is an @unchecked Sendable trait whose synchronization assumed serial planning, which isn't a documented guarantee — flagging it explicitly.
• A test cancelling itself in a trait (Test.cancel()) is still isolated by _determineAction's inner task group and does not affect siblings. Added a regression test that builds an eight-test plan where one test cancels in a trait and asserts the other seven still run.
• Uses structured withTaskGroup — the same primitive already used in _determineAction and the run loop — so no new unstructured tasks. Non-Darwin (Embedded / WASI / Windows) compilation is left to CI.

Measurements

A synthetic measurement to size the mechanism — deliberately a worst case, not a real-world figure. 1000 free-function tests, each with a trait whose prepare(for:) awaits ~1 ms (modeling an async .enabled(if: await …) condition) and with empty bodies, measured by toggling isParallelizationEnabled on the same build:

plan construction (1000 tests × ~1 ms async condition)	time
serial (today)	~1.75 s
concurrent (this PR)	~0.13 s

The fraction is this large only because the bodies are empty, so plan construction is essentially the whole run, and the condition is pure suspension. With real test bodies the fraction shrinks accordingly, and suites with no async trait work see no change at all. The only claim here is that the serial phase is not inherently sub-millisecond once trait preparation is async — which is the case this PR addresses.

Checklist:

• Code and documentation should follow the style of the Style Guide.
• If public symbols are renamed or modified, DocC references should be updated.

[grynspan]

Thanks for the PR! The code owners are going to review it soon. In the mean time, please let us know if you used an LLM/agent for any part of the work. Thanks!

[inju2403]

@grynspan
Yes — I've been studying how swift-testing builds its plan, and I used an LLM agent for the bulk of the implementation. I reviewed and verified everything before opening the PR.

If the project has a policy on AI-assisted contributions — or would rather not take them — just let me know and I'll respect that. Thanks!