The tag first, then the release made from it

Gitea will create a release for a tag that does not exist yet, and the tag
it writes is lightweight: no message, no signature. The forge page looks
correct and /admin/updates shows blank release notes, because the tag object
is where the application reads them from and there is nothing in it.

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

docs/notes/release-checklist.md

@@ -131,6 +131,12 @@ The one nobody does until it matters.
       the chats are there, and nothing in the log says a column is missing.
 - [ ] `/admin/updates` shows a version rather than a sha, and the release notes
       come from the tag.
+- [ ] Push the **signed annotated tag first**, then make the forge Release from
+      it — never the other way round. A Release created for a tag that does not
+      exist yet makes a **lightweight** one: no message, no signature, so the
+      forge page looks right and `/admin/updates` shows blank release notes.
+      The tag is what the application reads; the Release is a second window onto
+      the same text, for people who never install it.
 - [ ] Press Update. The service restarts and comes back.
 - [ ] Re-run `install.sh`. The channel does **not** move on its own. *(0.9.12.)*
 - [ ] `sudo ls -l /usr/local/lib/lembas/update.sh` — owned by root. If systemd's