Publish release candidates to a testing apt distribution

Pre-releases (versions with a hyphen) now upload their .debs to the
"testing" distribution instead of "stable", so servers following stable
never get an RC from apt upgrade. An RC can take its release notes from
its final version's section or Unreleased; the workflow checks the notes
with 'gitea-release.sh notes'. Also fix publishing RCs, whose .deb names
carry the Debian version (0.2.0~rc.1) and were rejected.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/development.md

@@ -185,7 +185,8 @@ files are embedded at build time, so rebuild jarld after changes.
 ## Releasing
 
 1. Move the "Unreleased" section of `CHANGELOG.md` under
-   `## [<version>] - <date>`.
+   `## [<version>] - <date>`. (A release candidate may skip this; see
+   below.)
 2. Put the version in `VERSION`.
 3. `make test && JARL_BIND_ROOT=... make e2e` (CI runs only `make test`;
    it has no BIND).
@@ -198,9 +199,31 @@ amd64 and arm64) and runs `scripts/gitea-release.sh`. That creates the
 Gitea release (the CHANGELOG section as notes; the tarballs, the CLI for
 Linux, macOS and Windows, the `.deb`s and `SHA256SUMS` attached) and
 uploads the `.deb`s to the owner's Debian registry, distribution `stable`,
-component `main` ([install.md](install.md#from-the-package-registry)). A
-version with a hyphen (`1.0.0-rc.1`) becomes a pre-release; its packages
-get version `1.0.0~rc.1`, which apt sorts before `1.0.0`.
+component `main` ([install.md](install.md#from-the-package-registry)).
+
+### Release candidates
+
+A version with a hyphen (`0.2.0-rc.1`, tag `v0.2.0-rc.1`) is a
+pre-release:
+
+* **On Gitea** it is marked "Pre-Release". Gitea doesn't count it as the
+  latest release: the repository page, `/releases/latest` and the API's
+  latest release keep pointing at the last stable one.
+* **The `.deb`s go to the `testing` distribution**, not `stable`. Their
+  version is `0.2.0~rc.1`, which apt sorts after `0.1.0` but before
+  `0.2.0`. So in `stable` an RC would reach every server on its next
+  `apt upgrade`. Servers that follow only `stable` never see RCs. A test
+  machine that also lists `testing` gets each RC, and then the final
+  `0.2.0` from `stable`, which supersedes it.
+* **Release notes**: its own `## [0.2.0-rc.1]` section if there is one;
+  otherwise the section of the version it leads up to (`## [0.2.0]`), or
+  else `## [Unreleased]`. So you can tag RCs while the changes are still
+  under Unreleased, and move them under `## [0.2.0]` for the real release.
+  A stable release still needs its own section.
+
+`scripts/gitea-release.sh notes` prints the notes a release would get
+(`VERSION=0.2.0-rc.1 scripts/gitea-release.sh notes`), and the workflow
+runs it as a check before building.
 
 Pushing the same tag again (`git tag -f`, `git push -f`) re-runs it, and
 the script replaces the attachments and packages, so a failed release can