Partial GitHub Actions reruns can preserve a red result after the primary failure is gone

When CI artifact names include the workflow run attempt, rerunning only failed jobs can make a downstream aggregator request artifacts that successful producer jobs never created for the new attempt. This applies to workflows that reuse successful jobs across attempts while consumers derive artifact names from the current github.run_attempt; it does not apply when every producer is rerun or artifact identity is passed explicitly from each producer.

Separate the original failure from rerun-induced failures. An ephemeral environment/setup failure may disappear on rerun, yet the run can stay red because the aggregator mixes attempt-1 producers with an attempt-2 consumer. A coherent full-workflow rerun diagnoses this distinction; the durable design is for consumers to use actual producer artifact identities rather than assuming one attempt number applies to every dependency.

Evidence/example — 2026-09-16: Shield PR #877, GitHub Actions push run https://github.com/e3-solutions/theft/actions/runs/35054903929. Attempt 1's generic egress lane stopped before tests because a local Supabase Docker port was already occupied. A failed-jobs-only rerun made that lane pass, but the audit requested attempt-2 Pylon and browser artifacts even though those successful producers were not rerun and had only attempt-1 artifacts. The same SHA's independent full PR-event run passed. This reproduces the failure mechanism previously observed on Shield PR #784; it is evidence about CI orchestration, not application correctness.