CI: build and publish the container image to GHCR

The Dockerfile's builder stage already runs the unit suite, so the workflow
deliberately has no separate test job -- a red test cannot produce an image.

After pushing, the published artifact is smoke-tested by digest: `--version`
covers a runtime stage missing a shared library, and `--check` against a
throwaway credentials file covers the config baked into the image. Both were
failure modes a green build would not have caught. The `--check` invocation is
verified locally against docker/openvpngate.conf.

`latest` follows the newest v* tag rather than the branch head; master head is
published as `master`. Registry paths are lowercased explicitly rather than
relying on metadata-action, since the same value is reused for the smoke test.

GHCR_TOKEN / GHCR_USER / GHCR_IMAGE override the built-ins so this still works
from a mirror or a Gitea/Forgejo runner, where the ambient token authenticates
to the wrong registry. On github.com none of them need to be set.

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

CLAUDE.md

@@ -136,6 +136,10 @@ image a different VPN client every week; and `docker/openvpngate.conf` overrides
 defaults that are silently wrong in a container — loopback listen addresses (a published port then
 reaches nothing) and relative state paths (the node history dies with the container).
 
+`.github/workflows/publish-image.yml` publishes that image to GHCR. It has no test job on purpose —
+the builder stage runs `ovg_tests`, so a red test cannot produce an image. If you ever make the
+Dockerfile skip the suite by default, CI stops testing anything and nothing will say so.
+
 `etc/openvpngate.conf` documents every key with its default and the reasoning. Admin HTTP (default
 `127.0.0.1:9080`, **no auth**) exposes `/status /nodes /sessions /health /metrics /healthz` and
 `POST /switch`; `/nodes` explains each node's score, which is the fastest way to understand a