ci: Consolidate test results reads the PREVIOUS attempt's shard artefact after rerun-failed-jobs (latest-by-id is the older upload) — a shard that re-ran green cannot turn the required check green #4303

Consolidate test results consolidates the PREVIOUS attempt's shard artefact after rerun-failed-jobs — a shard that re-ran green cannot turn the required check green

Measured, run 34823051999 (#4292, head 75ae0835)

The run now holds two artefacts named testResults-shard1:

id 10338854604  size 297521  created 08:38:28Z   ← attempt 1, carries the failure
id 10338734845  size 298484  created 08:49:55Z   ← attempt 2, green

actions/download-artifact@v8 with pattern: testResults-shard* reports Found 12 artifact(s) — 6 build-output-* + 6 testResults-shard* after its own per-name de-duplication — and the one it keeps per name is the highest id, which here is the OLDER upload: artefact ids are not monotonic across attempts (attempt 2's id is lower). So the consolidate reads the stale trx and re-declares the failure the re-run just cleared. The exit-marker gate reads the same directory and agrees, for the same reason.

Falsified as predicted — attempt 3 (rerun-failed-jobs of the consolidate alone, 08:52:50Z, job 103914885830): Found 12 artifact(s) → testResults-shard1 (ID: 10338854604, Size: 297521) again → the same ##[error] on the same test at 08:53:09Z, 3 min after the listing was provably settled (both artefacts visible over REST at 08:52:50Z). The choice is by id and structural, not a listing lag. This run cannot be made green by any re-run; only a new head (a new run id with fresh artefacts) can.

Why this matters

• A required check that cannot go green on a re-run turns every unattributed or infrastructure failure on a PR into a forced new push — exactly the shape ci: one automatic retry for named infrastructure transients #2921's automatic retry and the steward's queue re-runs were meant to absorb. Memex.Portal.Shared.Test host FailFast'd on the RSS guard (6384 > 6144 MiB, Reflection.Emit leak) — shard 5 of #4110 attempt 1; green on re-run, occurrence uncounted #4127's attempt 2 happened to pass because there the newer artefact drew the higher id.
• It is a gate reading an input it did not verify is the current attempt's — the class AGENTS.md's no-skip-trapdoor rule is about, one step over: not "the gate ran on nothing", but "the gate ran on the wrong run".

Fix direction (not band-aids)

The artefact a shard uploads should be attributable to its attempt, and the consolidate should read only the current attempt's set — e.g. name shard artefacts with ${{ github.run_attempt }} and filter on it, or download each shard's artefact by the ID the shard job outputs, never by name pattern. Deleting the stale artefact after a re-run is the same fix from the wrong end.

Refs #4300 (the unattributed failure that exposed it), #4127 (a re-run that passed by luck of the id), #2921.