ci: retry Node setup on the manifest-miss legs; fix trunk-red's close rule

[colinhacks]

Smoke (node 25.2) went red on main inside actions/setup-node, before nub's binary ran. Transient — the same leg passed next run.

actions/node-versions ships no 23.x/25.x, so four smoke legs fetch nodejs.org/dist/index.json live. That request retries only on 502/503/504, so a network blip kills the leg with no diagnostic (actions/setup-node#1136).

• Retry setup-node once in the smoke job.
• trunk-red cleared on any green CI, though seven workflows file the issue — CI is failing on main #550 was filed by WPT Worker and Node matrix, closed by a CI green. Now needs every reported workflow green.
• The gate named no failing leg. It now annotates each, and treats abandoned as red.

Refs #585

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
nub	Ready	Preview, Comment	Jul 28, 2026 6:42pm

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[pullfrog]

ℹ️ No critical issues — two minor robustness edges in the trunk-red close rule, inline.

Reviewed changes — two CI-workflow-only changes (no product code) that harden the Node smoke matrix against a transient setup-node failure and fix the trunk-red tracking issue's over-eager auto-close. Refs #585.

• Retry setup-node once on the manifest-miss smoke legs — the first actions/setup-node runs with continue-on-error: true and a second identical step retries only if: steps.setup-node.outcome == 'failure', so a lone nodejs.org/dist/index.json blip on the 23.x/25.x legs no longer reds the leg.
• node-matrix-gate now names the failing legs — gains permissions: actions: read + GH_TOKEN and, on red, enumerates the non-green jobs via gh api .../jobs instead of printing a bare "smoke failed"; cancelled/abandoned are treated as red (fail-closed).
• Rewrite trunk-red's close rule to require every implicated workflow green — parses the implicated workflow names from the issue body/comments and re-checks each one's latest main run, closing the tracking issue only when all are terminal-green (was: close on any CI success, the #550 false-clear).

The change is sound and unusually well-commented; the retry logic and the gate's fail-closed reading are correct. The two inline notes are robustness edges in the new close rule, both safe-direction (they bias toward leaving the issue open, not toward a false-clear) and non-blocking.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using Claude Opus ｜ 𝕏}

[pullfrog]

ℹ️ Treating cancelled as clearing a workflow is safe for the common merge-burst case — a superseding push means --limit 1 returns the newer run, not the cancelled one, so the cancelled run is never what's read here. The narrow gap is a cancel with no superseding run yet (a maintainer manually cancels a stuck run, or a runner-availability timeout): that cancelled run genuinely is the latest, nothing verified the fix, and this clears the workflow anyway.

The comment above ("cancelled is a superseded run, which the job-level if: above already treats as noise") conflates two paths — the job-level if: gates whether this trigger event fires, not what gh run list returns for an unrelated already-red workflow. Worth either dropping cancelled from the clearing set (fail-closed, consistent with the gate change) or tightening the comment to name the manual-cancel gap.

Technical details

# `cancelled` in the clearing set can false-clear on a non-superseded cancel

## Affected sites
- `.github/workflows/trunk-red.yml:96` — `success|cancelled|skipped) ;;` clears the workflow.
- `.github/workflows/trunk-red.yml:93-94` — comment justifies `cancelled` as "superseded run," but that reasoning only covers the merge-burst case.

## Required outcome
- A workflow whose latest `main` run is `cancelled` *without* a newer superseding run should not be read as green.

## Suggested approach (optional)
- Drop `cancelled` from line 96 so it falls to `*)` (still-red) — the fail-closed reading, matching the node-matrix-gate change in this same PR. Superseded-run convergence still holds because the newer run re-fires trunk-red when it settles.
- Or keep it and reword the comment to state the manual/timeout-cancel gap explicitly rather than implying it's fully covered.

[pullfrog]

ℹ️ This reported=$(...) pipeline is unguarded under set -euo pipefail. If gh issue view has a transient failure (rate limit, network blip), pipefail propagates its non-zero status even though sed/sort succeed on empty input, and set -e aborts the whole step. Contrast line 88's latest=$(gh run list ... || echo ""), which is explicitly guarded. The failure direction is safe (the step just fails and the issue is left untouched, self-healing on the next trigger), but the inconsistency is worth closing — e.g. append || true here too, or wrap the whole assignment. A legitimate empty match is already handled by the [[ -n "$reported" ]] fallback below.