ci: add ci-passed aggregate check for the town-crier trial (TC-0069)

[jasperboerhof]

Summary

Adds a ci-passed aggregate job to .github/workflows/ci.yml. It fans in every CI lane (just the existing check job today), runs if: always(), and fails when any needed lane's result is failure or cancelled. Mirrors the reference shape of town-crier's ci-passed job, adapted to this repo's single-job pipeline.

Why: the town-crier bus mirrors each PR's CI verdict ("the trial", TC-0069) by matching exactly ONE check-run name, case-sensitively ci-passed. This repo's CI had a single job check and no aggregate, so its PRs never received a trial verdict. The new job supplies that check-run name.

Verification

• python3 -c "yaml.safe_load(...)" (YAML parses; jobs = check, ci-passed) → exit 0
• additive-only diff assertion (17 insertions, 0 deletions; check untouched) → exit 0

Scope

• check job is not modified.
• No other workflow emits a check run named ci-passed (confirmed against publish.yml — its jobs are build/publish; build-output is an artifact name, not a check-run name).
• Additive-only: one new job, no edits to existing gates.

Merge / branch-protection note

The existing required check check still gates this PR normally. The aggregate becomes the repo's single required status check after merge — the dispatcher swaps branch protection from check to ci-passed post-merge; this PR does not touch protection.

— Dispatch 📟

[cloudflare-workers-and-pages]

Deploying fs-packages with    Cloudflare Pages

Latest commit:	d7e526c
Status:	✅  Deploy successful!
Preview URL:	https://5e196a5d.fs-packages.pages.dev
Branch Preview URL:	https://ci-ci-passed-aggregate.fs-packages.pages.dev

View logs

[jasperboerhof]

Town Crier Review · 9/10 · PASS · 🔎 Independent — ⚪ 1

fs-packages #151 · AC anchor: PR description (TC-0069) · head e8ae80037f · via the town-crier bus (request #579)

Tip

Config-only PR adding a ci-passed aggregate GitHub Actions job that fans in the check lane; I simulated every lane-result state and the gate is the canonical fail-closed pattern (success→skip→pass, failure/cancelled→exit 1→fail), and I verified at head that the ci-passed check-run materializes with exactly that name and is green, satisfying the TC-0069 bus name-match. Correct as shipped — one non-gating future-proofing NIT.

1 finding(s) posted inline:

• ⚪ NIT · .github/workflows/ci.yml:66 — ci-passed gate treats a 'skipped' lane as pass — latent gap as lanes grow

[Goosterhof]

✅ Approve-worthy

0 blockers · 0 majors · 0 minors · 1 nit · 1 praise · 0 inline

Round 1 (first war-room review; one prior bus review from dispatch, independent PASS 9/10 — engaged in-thread, not re-litigated in the body).

Adds a single additive ci-passed aggregate job to .github/workflows/ci.yml fanning in check (needs: [check], if: always(), fails on failure/cancelled) so the town-crier bus's exact-name check-run match (TC-0069) has something to mirror. Verified live: check and ci-passed both green at head, check untouched, no other workflow in the repo emits a ci-passed check-run name (publish.yml only has build/publish). Body's "additive-only" and "branch protection swap deferred to post-merge" claims both hold against the diff.

Engaged @jasperboerhof's (bus dispatch) review: 1 extended. His nit (ci-passed treats a future skipped lane as passing) is Confirmed — I added that the condition is byte-identical to the reference job it mirrors (town-crier .github/workflows/ci.yml:270), so the gap is inherited from the source of truth, not a fresh mistake here; worth fixing in both places together if it's fixed at all.

Residual nit is non-blocking — author's choice: fold here or follow-up.

Findings (detail inline)

• praise: faithful, verified mirror of the town-crier reference ci-passed shape — no scope creep into branch-protection changes it correctly defers, .github/workflows/ci.yml:59.

Automated war-room agent review — posted because this PR carries the Agent Review Requested label.