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>

docs/development.md

@@ -49,7 +49,7 @@ make            # bin/jarld, bin/jarl (CGO_ENABLED=0, version from ./VERSION),
                 # and bin/completion/{jarl,jarld} (bash completion)
 make test       # go vet, gofmt check, go test ./...
 make e2e        # scripts/e2e.sh
-make deb        # dist/jarl_<version>_<arch>.deb (DEB_ARCH=arm64 etc. cross-builds)
+make deb        # dist/jarl_<version>_<arch>.deb (server) and jarl-cli_<version>_<arch>.deb (DEB_ARCH=arm64 etc. cross-builds)
 ```
 
 ### The Debian package
@@ -70,7 +70,7 @@ To try the package without installing it on your machine:
 
 ```sh
 docker run --rm -it -v "$PWD/dist:/pkg:ro" debian:trixie \
-  sh -c 'apt-get update && apt-get install -y /pkg/jarl_*_amd64.deb && bash'
+  sh -c 'apt-get update && apt-get install -y /pkg/jarl_*_amd64.deb /pkg/jarl-cli_*_amd64.deb && bash'
 ```
 
 ### Shell completion
@@ -154,7 +154,40 @@ files are embedded at build time, so rebuild jarld after changes.
 
 ## Releasing
 
-1. Move the "Unreleased" section of `CHANGELOG.md` under the new version
-   and date.
+1. Move the "Unreleased" section of `CHANGELOG.md` under
+   `## [<version>] - <date>`.
 2. Put the version in `VERSION`.
-3. `make test && JARL_BIND_ROOT=... make e2e && make dist`.
+3. `make test && JARL_BIND_ROOT=... make e2e` (CI runs only `make test`;
+   it has no BIND).
+4. Commit, tag and push: `git tag v<version> && git push origin main v<version>`.
+
+The tag starts `.gitea/workflows/release.yml`, which checks that the tag
+matches `VERSION` and that `CHANGELOG.md` has the section, runs `make
+test`, builds everything (`make dist`, `make cli-dist`, `make deb` for
+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`.
+
+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
+simply be retried.
+
+Once, on Gitea:
+
+* Actions on for the repository (Settings → Repository → Actions), and a
+  runner with the `ubuntu-latest` label: act_runner's default, which runs
+  jobs in `docker.gitea.com/runner-images:ubuntu-latest`. The job
+  downloads Go itself (`actions/setup-go`, from `go.mod`), so the runner
+  needs internet access, or a mirror of the actions and Go.
+* A repository secret `RELEASE_TOKEN` (Settings → Actions → Secrets): an
+  access token (User settings → Applications) with the `write:repository`
+  and `write:package` scopes, from a user who can write to the repository.
+  The job's automatic token can't be relied on to publish packages.
+
+`scripts/gitea-release.sh` also runs by hand after the same builds, with
+`GITEA_URL`, `GITEA_REPO` (`owner/name`) and `GITEA_TOKEN` set; it needs
+`curl`, `jq` and `dpkg-deb`.