[gnacho]

What was missing

Trying davcloud required a toolchain: no tags, no releases, no image, and the
README started at git clone plus go build. The Dockerfile that already
existed was never built by CI and predated the versioned go.sum: its build
stage ran go mod tidy and stamped no version at all, so the image could not
even report what it was.

What this changes

• Dockerfile: modules now come from the versioned go.sum (go mod download over go.mod + go.sum), and version, commit and date arrive as
  build args, so the binary inside the image reports the tag it was built from.
  OCI labels added, including the license the README declares.
• release.yml (new): a v* tag builds linux/amd64 and linux/arm64
  static binaries with CGO_ENABLED=0, writes a .sha256 per binary,
  publishes the GitHub release with generated notes, and pushes a multi-arch
  image to ghcr.io/<owner>/davcloud tagged with the version and latest.
• ci.yml: new image job that builds the image on every push and pull
  request (single arch, nothing published) and runs -version inside it, so
  the Dockerfile cannot rot unnoticed again.
• Docs: README (en/es) opens the install section with the release download
  (checksum included) and the docker run path; deploy/README.md offers the
  released binary as the way to skip the toolchain; PLAN.md records the
  hardening now in production, adds the distribution phase and stops claiming
  "no containers" without qualification.

How it was checked

• go vet ./..., gofmt -l ., go mod tidy (no diff) and
  go test ./... -race -shuffle=on -count=1: all green.
• The go mod download layer was reproduced outside Docker with only go.mod
  and go.sum in an empty directory (exit 0): that is the layer that used to
  depend on go.sum existing.
• The command line the new README documents was run for real, with the same
  flags and a local port and directories (-addr :5232 -data-dir /data -ui-dir /app/ui -dev-user alice): PROPFIND /caldav/ -> 207, /carddav/ ->
  207. The example is not aspirational.
• actionlint (v1.7.12, built from source) on both workflows: no findings.
• Action versions are pinned to the latest release tag of each action, read
  from the GitHub API (setup-qemu-action@v4, setup-buildx-action@v4,
  login-action@v4).

Not covered here

• The image is built by this pull request in CI but published only by the
  release workflow. The v0.2.0 tag and the checks after it (assets, anonymous
  pull) come next, in the same issue.
• Production is untouched: the systemd deployment keeps the same binary and
  volume (0.2.0-dev, commit ac395f0, deployed 2026-10-18).

Closes #43