ci: add SBOM generation to release workflows

[otavio]

What

Every tagged release now generates CycloneDX SBOMs for all published Docker images and source code, attaches them to the GitHub release, and embeds them as OCI referrers on the container images.

Why

EU Cyber Resilience Act (Art. 13(1)) requires a machine-readable SBOM identifying top-level dependencies with each release. ShellHub had no SBOM generation.

Closes shellhub-io/team#97

Changes

• docker-publish.yml: Each community service (api, ssh, gateway, ui, ui-react, cli) now gets two SBOMs — one from the container image (Go modules, Alpine packages) and one from the source directory (catches npm dependencies bundled away in production nginx images). SBOMs are attached as OCI referrers via cosign and collected into the GitHub release by a new release-sboms job. Same pattern applied to the enterprise API image.
• build-agent.yml: New sbom job scans the pushed multi-arch agent image and attaches the SBOM as an OCI referrer. The vendored-tarball job generates an additional source-level SBOM from Go modules. Both are included in the draft release.
• Permissions: Both workflows gained contents: write, packages: write, and id-token: write at workflow level for release attachment, OCI push, and future cosign keyless signing.

Testing

• Validated locally with syft (via nix shell nixpkgs#syft) against dev images: API detected 99 Go modules + 26 Alpine packages, UI-React detected 1284 npm packages, agent detected 243 Go modules + 58 Alpine packages, agent source scan found 66 Go modules.
• Full end-to-end verification requires a tagged release push — confirm SBOMs appear as GitHub release assets and via cosign tree shellhubio/<service>:<tag>.

[github-actions]

Claude finished @otavio's task in 5m 48s —— View job

---

Code Review Complete

Reviewed 2 files across code quality, security, testing, language patterns, and architecture. 1 inline issue posted (medium severity).

The SBOM generation approach is solid — CycloneDX format, dual image+source scans, cosign OCI attachment, and release asset publishing all look correct. The anchore/sbom-action, cosign, and softprops/action-gh-release integrations are wired up properly with appropriate job dependencies.

The one issue flagged is that build-agent.yml sets workflow-level write permissions, but since it also triggers on pull_request, the build job (which only needs read access) gets unnecessarily elevated permissions on PR runs. Moving to job-level permissions would fix this.

---

To request another review round, comment /review.

[otavio]

/review

[github-actions]

Claude finished @otavio's task in 3m 8s —— View job

---

Code Review Complete

Reviewed 2 files across code quality, security, testing, language patterns, and architecture. No issues found.

The previous review's finding (workflow-level permissions too broad for PR builds in build-agent.yml) was correctly addressed in 79228de with job-level permissions on sbom and draft. The SBOM generation approach — CycloneDX format, dual image+source scans, cosign OCI attachment, and release asset publishing — all looks correct and well-structured.

---

To request another review round, comment /review.