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>

CHANGELOG.md

@@ -15,8 +15,20 @@ All notable changes to Jarl are documented here. The format follows
   and prints the steps to install Jarl and adopt the configuration
   (docs/development.md).
 
+### Changed
+
+- Release candidates (tags like `v0.2.0-rc.1`) publish their `.deb`s to a
+  separate `testing` distribution of the package registry instead of
+  `stable`. Servers that follow `stable` can't pick up an RC with
+  `apt upgrade`. An RC may also take its release notes from the
+  `## [0.2.0]` or `## [Unreleased]` section of the CHANGELOG instead of
+  needing its own (docs/development.md, "Release candidates").
+
 ### Fixed
 
+- Publishing a release candidate failed: `scripts/gitea-release.sh`
+  rejected its `.deb`s, whose names carry the Debian version
+  (`0.2.0~rc.1`) instead of `0.2.0-rc.1`.
 - `jarld import` no longer warns that a zone with `allow-update { none; }`
   uses dynamic updates (validation already allowed it).
 - docs/cli.md gives the CLI configuration file's location on macOS