Add a container image for the server

Why: the server is a single static binary with no dependencies, so its
container should be nothing but that binary. Shipping one also makes the
master key easy to lose, which needed handling rather than documenting.

What:
- Dockerfile: two stages, runtime is scratch plus the binary and a CA bundle
  for reaching an OIDC provider, running as uid 65532. About 9 MB. The build
  stage copies only go.mod, cmd/keeporgd and internal, so client or docs
  changes do not invalidate it.
- The image has no shell, so HEALTHCHECK runs `keeporgd -healthcheck`, a new
  flag that probes /healthz on the configured address and exits non-zero
  with a reason. podman needs --format docker to keep the healthcheck at
  all, which the Makefile passes when it picks podman.
- New -master-key-file flag, so a mounted secret works without a config file.
- The server now checks at startup whether the master key still opens the
  stored vault keys, and says so. Without it, a container restarted without
  its key discovers the problem one failed merge at a time.
- make docker, docker-run and docker-save; a compose example with read_only,
  cap_drop ALL and no-new-privileges.
- The client and the server now version independently, so their Debian
  changelogs are split per package and `make changelog` takes PKG=.
  Server 0.3.0; the clients stay at 0.2.0.

Proved: built with podman and run. The container serves /healthz and /web,
its own healthcheck reports healthy, and a vault created through it was
edited from the same base by keepassxc-cli twice, merged by the server into
version 3, and read back with both entries intact. Restarted without the
master key it warns "1 of 1 stored vault keys do not open with this master
key" and answers a merging push with 409 merge_failed, leaving the vault
untouched; restored, it logs "1 vault keys available for merging" and merges
again. The same key supplied through -master-key-file from a mounted file
works identically. Both .deb packages build with their own changelog, and
make check is clean.

docs/HANDOVER.md

@@ -34,7 +34,9 @@ internal/client/       shared client engine: API wrapper, merge policy, mirror
 internal/secret/       password verifiers, tokens, identifiers
 internal/totp/         RFC 6238 second factor
 android/               Android client: DocumentsProvider, sync service, UI
-packaging/             deb, macOS bundle and DMG, Windows zip, systemd units
+Dockerfile             the server's container image, built from scratch
+packaging/             deb, macOS bundle and DMG, Windows zip, systemd units,
+                       container compose example
 scripts/               package builders, version bump, changelog
 versions.mk            the one place every platform's version lives
 Makefile               the only entry point for building and publishing
@@ -404,6 +406,43 @@ keeporg db -id <db-id> -strategy merge
 keeporg db -id <db-id> -forget-password    # the server can no longer read it
 ```
 
+### Running it in a container
+
+```sh
+make docker                       # keeporgd:<version>, about 9 MB
+make docker-save                  # dist/keeporgd-<version>-oci.tar
+```
+
+The image is `scratch` plus the static binary and a CA bundle, running as
+uid 65532. There is no shell in it, so `HEALTHCHECK` runs the binary with
+`-healthcheck`, which probes `/healthz` on the configured address.
+`make docker` uses podman when it is installed and docker otherwise; podman
+needs `--format docker` for the image to keep its healthcheck, which the
+Makefile passes.
+
+Two directories matter, and the whole point is that they are separate:
+
+- `/var/lib/keeporg` — state and blobs. Mount a volume.
+- `/etc/keeporg` — `server.json` and, by default, the master key.
+
+**Give the master key somewhere durable**, either `KEEPORG_MASTER_KEY` from
+your secret store, or `-master-key-file` pointing at a mounted secret, or a
+volume on `/etc/keeporg`. A container started with none of those mints a key
+into its own layer and loses it on the next `run`. That is survivable but
+annoying: the vaults still open for their users, and only merging stops. The
+server says so at startup —
+
+```
+WARNING: 1 of 1 stored vault keys do not open with this master key.
+```
+
+— and a merging push then answers `409 merge_failed` rather than corrupting
+anything. Restore the original key and it resumes.
+
+`packaging/docker/compose.yaml` is a worked example with `read_only`,
+`cap_drop: ALL` and `no-new-privileges`; the server writes one directory and
+needs no capabilities.
+
 ## Versioning and publishing
 
 `versions.mk` is the only place a version lives, one per platform plus the