Release - Supply-chain hardening (sign + SBOM + provenance + attest)

[eminwux]

Context

Release-pipeline supply-chain work is currently spread across 6 issues
(#55, #57, #58, #59, #61, #63), all priority:C, that describe one coherent
goal: ship signed, attested, SBOM-bearing release artifacts. They depend on
each other (sign → SBOM → attest), so tracking them as siblings has
inflated the backlog without adding clarity.

Consolidating into a single tracking issue.

Proposal

Phased delivery, each phase a landable PR:

• Phase 1 — Generate SHA256SUMS for all release assets and upload with the GitHub Release (tracked separately in Release - Generate SHA256SUMS for all release assets and upload with the GitHub Release #56 — already standalone, kept as the entry point)
• Phase 2 — Sign SHA256SUMS (GPG or minisign) OR sign each asset with cosign (was Release - Sign SHA256SUMS (GPG or minisign) OR sign each asset with cosign #57)
• Phase 3 — Sign release binaries in CI (was CI - Sign binaries #55)
• Phase 4 — Cosign-sign pushed container images, digest-based (was Images - Cosign sign pushed images (digest-based) #61)
• Phase 5 — Generate SBOMs for binaries and images via syft, upload with the Release (was SBOM - Generate SBOMs for binaries and images (syft) and upload with the Release #59)
• Phase 6 — Cosign-attest SBOMs, linking SBOM → image digest and binary artifacts (was SBOM - Cosign attest SBOMs (link SBOM → image digest and binary artifacts) #63)
• Phase 7 — Add SLSA / GitHub-attestation provenance for binaries (was Supply Chain - Add provenance for binaries #58)

Acceptance criteria

• Each phase ships independently and verifiably (cosign verify, syft inspect, slsa-verifier).
• Release-page README documents how downstream consumers verify each artifact.
• Existing make release flow continues to work without manual signing steps.

Notes

Replaces #55, #57, #58, #59, #61, #63. #56 (SHA256SUMS generation) stays
separate as the gating prerequisite — it can land before this epic begins.