feat: sign the release checksum list

SHA256SUMS.txt sat beside the artifacts it vouches for, so whoever could
rewrite a release rewrote the list with it. The packs were already
reproducible, which answers corruption and lets a third party rebuild an
archive byte for byte; nothing answered a rewritten release.

The list is now signed with an ed25519 key kept for this alone, and the
public half is allowed_signers at the repository root, so verification
does not go through the release page: ssh-keygen -Y verify against the
committed file, then sha256sum --check. Rehearsed on all three outcomes:
a good signature, a tampered pack caught by the sums, a rewritten list
caught by the signature.

The release steps sign and upload the signature, the README points a
downloader at the procedure, and the reproducibility section says what
each half proves. Rotation keeps retired lines so past releases stay
verifiable. Three tests hold the trust root, the signing step and the
documented principal in agreement.

wiki/architecture.md

@@ -160,6 +160,9 @@ regional files are never collapsed merely because their display label matches.
 A pack is a function of its inputs. Two builds from the same collection and
 the same `database.json` produce the same bytes, so a third party can rebuild
 a published pack and compare it against the checksum in `SHA256SUMS.txt`.
+That list is signed with a release key whose public half is `allowed_signers`
+at the repository root, so the comparison does not rest on the release page
+being intact: see [verifying a release](release-process.md#verifying-a-release).
 
 Three things make that hold. Generated members (`README.txt`, `manifest.json`)
 carry a fixed date rather than the wall clock, and the manifest's `generated`