Release pipeline post-mortem — v7.58.0

Branch fix/release-pipeline-post-mortem Fixes 2 pre-existing bugs surfaced by PR #1426 Missing assets on v7.57.0, v7.58.0

Bug #1 — SBOM + attestation silently skipped

v7.57.0 and v7.58.0 both shipped with zero release assets. No SBOM, no Sigstore attestation, no supply-chain provenance — even though every step existed in release.yml. Cause: once release-please started creating the GitHub Release (which it does automatically), the if: steps.check.outputs.exists == 'false' guard on every downstream step turned the whole pipeline into a no-op.

The over-gated pattern

Beforev7.58.0

# .github/workflows/release.yml
- name: Check if release exists
  id: check
  run: if gh release view "$TAG" ...

- name: Create GitHub Release
  if: steps.check.outputs.exists == 'false'
- name: Setup Node.js for SBOM
  if: steps.check.outputs.exists == 'false'    <-- silently skipped
- name: Generate SBOM (CycloneDX)
  if: steps.check.outputs.exists == 'false'    <-- silently skipped
- name: Upload SBOM to release
  if: steps.check.outputs.exists == 'false'    <-- silently skipped
- name: Attest build provenance
  if: steps.check.outputs.exists == 'false'    <-- silently skipped

Afterthis PR

# .github/workflows/release.yml
- name: Check if release exists
  id: check
  run: if gh release view "$TAG" ...

- name: Create GitHub Release
  if: steps.check.outputs.exists == 'false'   <-- only this is gated
- name: Setup Node.js for SBOM
- name: Generate SBOM (CycloneDX)
- name: Upload SBOM to release
  run: gh release upload "$TAG" --clobber    <-- idempotent re-run
- name: Attest build provenance                <-- runs every time;
                                                   attestations append-only
Evidence for the bug
gh release view v7.57.0 --json assets{"assets": []}
gh release view v7.58.0 --json assets{"assets": []}
Why the SBOM step can safely re-run
gh release upload --clobber overwrites existing assets with the same name. Sigstore attestations are append-only (each run adds a new attestation; old ones stay verifiable). So running SBOM + attestation on an already-existing release has no destructive effect.
Why not backfill v7.57.0 / v7.58.0
Backfill would require deleting + re-tagging, which re-triggers release-please and creates churn. The fix is forward-only — v7.58.1 onward will have SBOMs and attestations.