PR CI builds the Darling and Lite test projects in parallel jobs (#5955)

[erikdarlingdata]

Fixes #5955.

Claude posting for Erik Darling.

#5955: the two test projects build in parallel jobs

guard-build built Darling.Tests and Lite.Tests in sequence on one runner, and every shard waited for it. It now builds Darling.Tests only (same id, so the Darling shards, darling-linux, darling-tree-guards and darling-pg keep their needs), and a new guard-build-lite job builds Lite.Tests. Both start from gate alone.

• Darling shards, the Linux image and the whole-tree guards need guard-build. The four Lite shards need guard-build-lite.
• guard-tests runs the Guard classes of both suites, so it needs both builds. guard-cancel, darling-pg-result and lite-tests-result read both build results, so a red build of either project still ends all the required checks red.
• Artifact names, output names and shapes (guard-test-build-darling, guard-test-build-lite, darling_build_artifact, lite_build_artifact, the origin file) are unchanged. The docs-only decision is repeated in the Lite job (same filter, pinned equal to the build job's by GuardStageWorkflowTests).
• Cost: one more checkout, setup-dotnet and restore on a runner.

Measured, last two successful dev push runs since #5952 (38927468663 and 38934287500; only two exist, older runs still had the single-stage Guard): the job took 361 s and 355 s. Steps: checkout 14-15 s, setup .NET 53-62 s, restore 8-11 s, build both projects 246 s (both runs), uploads 9-10 s and 11-12 s. Every shard started 2-3 s after it ended.
Local clean Release builds on this laptop took 71 s for Darling.Tests and 49 s for Lite.Tests (ratio 59:41). Applying that ratio to the 246 s of CI build time gives about 146 s and 100 s. Expected: the Darling shards start about 110 to 115 s earlier (about 1.9 minutes), the Lite shards about 150 to 160 s earlier (about 2.6 minutes). This is an estimate from the ratio, because CI times the two builds as one step. The first run of this PR will show the real numbers (the two jobs' durations). The Darling shards are the long pole (they ran 9 to 15 minutes), so the wall-time gain of a run is the Darling figure.
The GuardStageWorkflowTests pins that describe the job shape were updated (needs lists, filter copy for both jobs, one build job per project, uploads, the consumers' producer job).

Test plan

• python -c "import yaml; yaml.safe_load(open('.github/workflows/build.yml'))" is fine.
• GuardStageWorkflowTests (Darling.Tests): 16 of 16 pass. Darling.Tests LockedModeRestoreCoverage, DarlingPathFilterGate, CiShard*, CiClusterWorkerSizingTests, every *Census* and *Ratchet* class: 559 run, 0 failed, 1 skipped.
• The workflow itself cannot run locally. The first CI run of this PR shows the real durations of Guard tests build (Darling) and Guard tests build (Lite).
• Full suite not run on this laptop; CI decides.

Coordinator note

The #5946 half (a Cost=Slow map-coverage gate) was built in this branch and then reverted in 02977f7: run against the last five merged pull requests with all 101 candidate classes tagged, it skipped 0 classes on every one. #5946 is closed as measured, with the numbers.

CHANGELOG entry

SECTION: Fixed
ENTRY:

• PR CI builds the two test projects in parallel ([CI: build the Darling and Lite test projects in parallel jobs so each shard waits only for its own #5955]) - the Darling and Lite shards waited for one job that built both test projects in turn (about 6 minutes); each now waits only for its own project's build job, so the Darling shards start about 2 minutes earlier and the Lite shards about 2.5 minutes earlier. A red build of either project still turns the required checks red.
  REF:
  [CI: build the Darling and Lite test projects in parallel jobs so each shard waits only for its own #5955]: CI: build the Darling and Lite test projects in parallel jobs so each shard waits only for its own #5955

[claude]

Non-blocking observation: this step, and every other step in guard-tests after checkout (the workflow-filter, actionlint, setup-dotnet, both artifact fetches, the workspace/sha check, and the two "run"/upload steps), is gated only on needs.guard-build.outputs.run == 'true', never on needs.guard-build-lite.outputs.run. Since the two producers now decide independently (each repeats its own docs-only filter), a transient failure in guard-build before its decide step runs (e.g. a flaky checkout or dorny/paths-filter) would leave needs.guard-build.outputs.run unset and skip the whole guard-tests job — including this Lite fetch and the Lite guard-class run — even if guard-build-lite succeeded cleanly with a valid artifact.

This doesn't look like a real merge-safety gap: guard-cancel and the GUARD_RESULT expressions in darling-pg-result/lite-tests-result already read needs.guard-build-lite.result directly (not through guard-tests), so a guard-build-lite success in that scenario wouldn't paper over a real guard-build failure — the required checks still go red via guard-build's own result. It's also exactly what ADocsOnlyChange_LeavesTheGuardJobGreenHavingBuiltNothing (GuardStageWorkflowTests.cs:262) pins today, so it reads as intentional. Flagging only because the asymmetry — gating steps that consume both producers' artifacts on just one producer's run output — is easy to miss on a future edit.