Split the packages, publish releases from Gitea Actions, release 0.1.0

make deb now builds two packages: jarl-cli (the CLI, its completion and
the ACME hooks, no scripts) and jarl (the server), which depends on
jarl-cli of the same version.

Pushing a v* tag runs .gitea/workflows/release.yml: it tests, builds the
tarballs, the CLI for Linux, macOS and Windows (make cli-dist) and the
.debs for amd64 and arm64, then scripts/gitea-release.sh creates the
Gitea release and uploads the .debs to the Debian package registry, so
servers install and upgrade with apt. The stats package's inode lookup
is split by OS so the CLI builds for Windows.

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

README.md

@@ -67,8 +67,9 @@ error: www.adbraun.lol has a CNAME, so it can't have any other records (found A)
   fallback.
 * One static Go binary for the daemon (web UI embedded, SQLite built in) and
   one for the CLI, run by a sandboxed systemd service as an unprivileged
-  user. `make deb` builds a Debian package, and both come with bash
-  completion.
+  user. Releases come as Debian packages in an apt repository (server and
+  CLI separately) and as standalone CLI downloads for Linux, macOS and
+  Windows; both binaries have bash completion.
 
 ## Quick start
 
@@ -76,7 +77,8 @@ On a Debian/Ubuntu BIND 9.20 server ([install.md](docs/install.md) has the
 details):
 
 ```sh
-make deb && sudo apt install ./dist/jarl_*.deb   # or: make && sudo make install, see install.md
+sudo apt install jarl     # from the Gitea package registry (install.md shows adding it)
+# or build it: make deb && sudo apt install ./dist/jarl*_amd64.deb, or make && sudo make install
 sudo -u jarl jarld init                    # database + first administrator
 sudo -u jarl jarld import                  # read the current named.conf and zones
 sudo jarld adopt                           # switch named over (keeps a backup, rolls back on failure)