ci(release-verify): per-asset signature verification, plus SHA256SUMS gate

[Jaro-c]

What

Two real security improvements, in the reusables that gate every release.

1. installer-contract.yml — assert the release workflow publishes a SHA256SUMS manifest. The install scripts verify downloaded binaries against this file; a release that stops producing it is a silent breaking change (install.sh fetches the URL and gets a 404 mid-installer). The check matches the presence of the path on the manifest side, not the upload step name on the workflow side, so it stays valid across workflow renames.

2. release-verify.yml — per-asset signature verification. Iterates every per-asset .sig (per-binary, per-deb, per-SBOM, per-installer), not just SHA256SUMS.sig. The signature covers each binary independently, so a manifest re-signed to legitimize a swapped binary still fails the check (a manifest-only check would pass that case). Uses the org Ed25519 release key as a new input (release-pubkey-b64) with the current key as default. Skipped for manifest-kind: go because Go modules are versioned by the tag itself.

Why this matters

This is the same gap that Glyndor/podup#1359 closed in podup's own release workflow: a per-binary substitution where the manifest could be re-signed to match a swapped binary. The org reusable should not require every consumer to reimplement it.

The manifest-only SHA256SUMS check in installer-contract.yml closes a separate failure mode: install.sh keeps fetching the manifest URL even when the release stops producing it, and gets a 404 mid-installer. Catching the missing SHA256SUMS asset at PR time is the cheap fix.

Test plan

• Run act or a real workflow dispatch with a known-good release and confirm both checks pass
• Run with a release that omits a per-binary .sig and confirm release-verify fails with a clear message
• Run with a release that omits SHA256SUMS and confirm installer-contract fails

Signed-off-by: Jose 75870284+Jaro-c@users.noreply.github.com