chore: generate and attach CycloneDX SBOM to every release

[scops]

Summary

• New .github/workflows/sbom.yml. Triggers on release: published (plus workflow_dispatch for backfilling existing releases).
• Generates a CycloneDX 1.6 JSON SBOM of the production dependency tree via @cyclonedx/cyclonedx-npm --omit dev and uploads sbom.cdx.json as a release asset.
• New npm run sbom script — same command, runnable locally so consumers and audits can reproduce the artefact.
• @cyclonedx/cyclonedx-npm added as a devDependency (pinned via the lockfile).
• sbom.cdx.json added to .gitignore.

Why

Compliance regimes (SLSA, EO 14028, EU CRA drafts) increasingly expect a verifiable list of every transitive dependency that ships in an artefact. Attaching the SBOM at release time means consumers can diff it across versions to spot supply-chain changes without re-running npm ls.

Notes

• Used cyclonedx-npm rather than the more generic cyclonedx-cli because it parses package-lock.json natively and produces a tighter SBOM. Output validated locally: CycloneDX 1.6, 102 production components.
• The workflow uses --clobber on gh release upload so re-running it (via the manual workflow_dispatch for an older release) replaces the existing asset rather than failing.
• No SBOM was attached to v2.0.0 / v2.1.0 / v2.2.0. After this merges, we can backfill by triggering Actions → SBOM → Run workflow → tag: v2.2.0 (etc.).

Test plan

• npm run sbom produces a valid sbom.cdx.json (CycloneDX 1.6, 102 components, dev deps excluded).
• npm test — 48/48 still passing (no runtime change).
• CI green on this PR.
• Once merged, dispatch the workflow against v2.2.0 to backfill that release. Future releases attach automatically.