release: nothing shipped is signed or attested — .sha256 files sit in the same release as the artifacts

[plusky]

Subtask of #169 (worth doing now, ranked 2). The largest genuine gap in the
assessment.

Nothing bugwarden ships is signed or attested. The .sha256 files live in the
same release as the artifacts they describe, so anyone who can alter one can
alter the other — integrity with zero authenticity. For a guard product people
mount in front of Bugzilla, that is the wrong default.

Suggested direction

• actions/attest-build-provenance on the tarballs, .deb and .rpm — about
  ten lines plus id-token: write on that job.
• provenance: mode=max on the existing docker/build-push-action.
• crates.io already gets provenance via Trusted Publishing; nothing to do there.
• Consider cargo auditable so downstreams can run cargo audit bin against a
  shipped binary rather than trusting the release notes.

Care needed

This touches release.yml, which runs only on a tag push and cannot be
rehearsed by merging. Whatever lands should be reasoned about in the same PR as
#169's actionlint item if that goes first, or verified some other way — a
provenance step that fails at tag time fails an irreversible operation.