feat(ci): publish multi-arch Docker image to GHCR (#88)

Issue #88's biggest blocker was that docs and README pointed at
ghcr.io/mbombeck/healthlog:latest, but no workflow ever pushed an
image — every self-hoster trying to follow the docs hit "manifest
unknown".

This adds .github/workflows/docker-publish.yml. The workflow:

- Triggers on push to main, on v* tags, on PRs (build only, no push),
  and via workflow_dispatch
- Builds linux/amd64 + linux/arm64 multi-arch images via buildx
- Tags with `latest` (main only), semver (`1.2.0`, `1.2`), branch name,
  PR number, and short SHA — using docker/metadata-action defaults
- Attaches SLSA build provenance and an SBOM to every image
- Caches build layers in GitHub Actions cache for fast iterations
- Uses concurrency group + cancel-in-progress so superseded runs stop

The bundled docker-compose.yml now references
`ghcr.io/mbombeck/healthlog:latest` as the primary `image:` and keeps
`build:` as a fallback so contributors can still
`docker compose up --build` against their working tree.

SECURITY.md gains a Supply Chain section explaining where images come
from, how to verify provenance and SBOMs, and how to pin a specific
version. README's Quick Start updated to reflect that no build is
needed for self-hosters.

The first run of this workflow on main will publish the image; until
then `docker compose up` will fall back to the `build:` block.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

docker-compose.yml

@@ -1,5 +1,12 @@
 services:
   app:
+    # Pre-built multi-arch images are published to GHCR by
+    # .github/workflows/docker-publish.yml on every push to main and on
+    # tagged releases. Pin to a specific version in production:
+    # e.g. ghcr.io/mbombeck/healthlog:1.2.0
+    image: ghcr.io/mbombeck/healthlog:latest
+    # Fallback build context: if the image is not yet in the registry,
+    # or you want to test local changes, run `docker compose up --build`.
     build:
       context: .
       dockerfile: Dockerfile