P2: Sign release artifacts and document how to verify them

Why

docs/operations.md says plainly that nothing Vole writes is signed. SHA256SUMS catches corruption in transit, but anyone who can write to the release page can replace a binary and its checksum together, so the file proves nothing about who made it.

Scope

• Sign dist/SHA256SUMS in the release workflow, so one signature covers every attached file.
• Settle how the private key reaches the build, and write the decision down. Vole has no secret store, and a release job runs in a container the same way a CI job does, so the options are: a maintainer signs by hand and attaches the signature with vole release attach; the key lives in the release runner’s image; or the runner is started with it in the environment. Prefer whichever keeps the key off any host that runs a workflow job.
• Publish the public key in docs/releases.md with copy-pasteable verification steps, and make the signature downloadable from the release.
• Decide whether vole release attach should refuse or warn on an artifact whose signature does not match, or whether checking stays an operator step.

Acceptance

• docs/releases.md has a verification recipe that works on a clean machine holding only the public key.
• A tampered artifact fails verification.
• The private key is not in the repository, a workflow file, or a workflow log.

Part of #14.