Updater: sign the release manifest (ed25519) instead of trusting the publisher

[vstrelnikof]

The self-updater verifies each download's SHA-256 against latest.json — which catches a corrupted transfer or a tampered CDN, but the checksum lives in the same GitHub release as the artifact, so an attacker who can publish a release can publish both. We say this plainly in the README rather than pretending otherwise; the fix has been designed but not built.

Manifest.signature is already reserved in the manifest schema for a detached ed25519 signature. What's needed:

1. Signing: a step in the release workflow that signs the manifest. Key custody is the interesting part — options include an offline signing step by the maintainer (upload the signed manifest as a follow-up asset) vs. a CI secret (weaker: same account compromise applies). Proposal welcome as part of the PR.
2. Verification: the public key ships baked into the binary; poltertype-update rejects a manifest whose signature is missing or wrong once the binary expects one.
3. Rollout: old binaries ignore the field (already true — it's reserved), new binaries require it. Needs one release where the manifest is signed but not yet required, then flip.
4. Docs: the README's "checksum-verified, not signed" caveat and the site's privacy/download copy get to upgrade their claim — but only when this actually ships.

Where to look: crates/poltertype-update/ (manifest fetch + verify), .github/workflows/release.yml, docs/DECISIONS.md entry from 2026-07-13 for the original design discussion.