Release notes that are not forty lines of base64

Found by documenting it. `_notes_for` stripped `-----BEGIN PGP SIGNATURE-----`
from an annotated tag's contents and nothing else, and which header appears
depends on `gpg.format`: `openpgp` writes that one, `ssh` writes
`-----BEGIN SSH SIGNATURE-----`. This repository signs with an SSH key, so the
first signed release tag would have rendered its whole signature block as the
release notes on the update page.

`%(contents:subject)` and `%(contents:body)` would have avoided the question,
and would also have thrown away every blank line in a body written as a list --
which is what release notes are.

The suite caught the other half of the same change: `tag.gpgSign` makes a bare
`git tag <name>` behave as `-s`, so the lightweight tags a test was making now
wait for an editor it does not have.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

deploy/README.md

@@ -73,7 +73,10 @@ onto a release candidate on the strength of a hyphen. A prerelease is something
 you check out by name.
 
 Release notes travel inside **annotated** tags, so `git tag -a v1.1.0 -m "…"` is
-what puts them on the update page. No forge API is involved anywhere — which
+what puts them on the update page. Tags here are **signed** (`tag.gpgSign`), and
+the notes render the same either way — `updates._notes_for` cuts the
+`-----BEGIN SSH SIGNATURE-----` block off `%(contents)`, which would otherwise be
+forty lines of base64 on the page. No forge API is involved anywhere — which
 matters more than it sounds: a token on the deployment host to answer a
 read-only question about version numbers is a bad trade, it would tie this to
 one forge, and the Gitea API this was checked against returns a 500 from a