Release setup: tarballs, Gitea workflow, apt registry

make dist builds tarballs for linux/amd64 and linux/arm64. A pushed v*
tag runs .gitea/workflows/release.yml, which checks the tag against
VERSION and the CHANGELOG, tests, builds the tarballs and the .debs
(amd64, arm64) and publishes them with scripts/gitea-release.sh: a Gitea
release, and the .debs in the Debian registry (stable, or testing for a
release candidate). As in Housecarl and Steward; no cli-dist, Guard is
Linux only. docs/development.md has the steps, docs/install.md the apt
source.

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

docs/development.md

@@ -0,0 +1,49 @@
+# Developing Guard
+
+[AGENTS.md](../AGENTS.md) has the layout and the ground rules.
+
+## Building and testing
+
+```sh
+make            # bin/guard and its bash completion
+make test       # go vet, gofmt check, go test ./...
+make e2e        # scripts/e2e.sh: needs Docker and ../housecarl
+make deb        # dist/guard_<version>_<arch>.deb
+make dist       # dist/guard-<version>-linux-<arch>.tar.gz (amd64, arm64)
+```
+
+**Unit tests** need neither Housecarl nor a journal: the daemon tests
+ban into a fake Housecarl, the journal test runs a fake journalctl
+(`GUARD_JOURNALCTL`), and `TestPresets` runs each preset over its sample
+lines in `testdata/presets/`.
+
+**The e2e test** borrows Housecarl's lab: a router container (Debian 13,
+nftables 1.1.3, the `housecarl-nft` image that Housecarl's `make e2e`
+makes) runs housecarld built from `../housecarl` (or `HOUSECARL_SRC`),
+a LAN server runs Guard over a log file, and a host on the internet
+misbehaves. It checks a ban at the router (one port, for that server
+alone), `never_ban`, bans waiting while Housecarl is down, and Guard on
+the router banning scanners from Housecarl's log of dropped packets.
+`KEEP=1` leaves the lab running; `DOCKER_HOST` points at another Docker
+daemon.
+
+The systemd sandbox is only tested by installing the package in a
+container that runs systemd (`--privileged --cgroupns=host /sbin/init`).
+
+## Releasing
+
+As for Jarl, Steward and Housecarl:
+
+1. Move "Unreleased" in `CHANGELOG.md` under `## [<version>] - <date>`.
+   A release candidate may leave it there.
+2. Put the version in `VERSION`, and update the README's status line.
+3. Run `make test && make e2e`.
+4. Commit as "Release X", tag it `git tag -a vX -m "Guard X"`, and push.
+
+The tag starts `.gitea/workflows/release.yml`, which checks the tag
+against `VERSION` and the CHANGELOG, runs the tests, builds the tarballs
+and the `.deb`s (amd64, arm64), and publishes them
+(`scripts/gitea-release.sh`): a Gitea release with the notes and the
+files, and the `.deb`s in the owner's Debian registry, `stable` for a
+release and `testing` for a release candidate. It needs the repository
+secret `RELEASE_TOKEN` (`write:repository`, `write:package`).