build: move releases to CI and trim the Makefile

Merging a pull request into main is now the whole release. A Gitea
Actions workflow derives the CalVer tag, builds the image and pushes
it with :latest, so nothing is built locally any more.

That made image/push/release redundant, and with them the .release-tag
state file and the main-branch guard — the workflow only runs on main,
which is protected, so the guard had nothing left to catch. The digest
verification went too: it guarded a `make -j` race between image and
push that cannot happen in a single CI job.

seed, icons and vendor ran a few times a year and are written out in
the README instead. Makefile: 151 lines to 71.

Docs referenced the removed targets in sixteen places, including a
CONTRIBUTING note claiming the branch check "has to be local".

PRD.md

@@ -372,22 +372,27 @@ Explicitly *not* React.
 
 ## 10. Deployment
 
-Images are built locally, pushed to a private container registry, then pulled
-on the server and run with Docker Compose.
+Images are built by CI, pushed to a private container registry, then pulled on
+the server and run with Docker Compose.
 
 - **Branches**: `main` carries released versions only, so its history is the
   deployment history and every release tag points into it. Development happens
   on `dev`, and `main` is protected on the remote: it accepts no direct
-  pushes, so a release arrives as a pull request from `dev`. `make image`
-  additionally refuses to run outside `main` — that one has to be local,
-  because the tag and the image are made before anything reaches the remote.
+  pushes, so a release arrives as a pull request from `dev`. The release
+  workflow runs only on `main`, so a release cannot be built from anywhere
+  else and nothing needs to check for it.
 - **Versioning**: CalVer `vYYYYMMDD-N`, where `N` is the Nth build of that
-  day. `make image` derives `N` by counting the day's existing git tags,
-  creates the new tag, and bakes the version into the binary through
-  `-ldflags -X main.version`. `make release` builds, tags and pushes.
-- **Tooling**: a `Makefile` is the single entry point — `make` on its own
-  lists every target. Build, test, lint, format, image and compose commands
-  all live there rather than in loose scripts.
+  day. The release workflow derives `N` by counting the day's existing git
+  tags, creates the new tag, and bakes the version into the binary through
+  `-ldflags -X main.version`.
+- **CI**: Gitea Actions, workflows in `.gitea/workflows/`. `check.yaml` runs
+  `make check` on every push to `dev`; `release.yaml` builds and pushes the
+  image when a pull request merges into `main`. Merging is the release —
+  there is no local build step.
+- **Tooling**: a `Makefile` covers development — `make` on its own lists every
+  target. Build, test, lint, format and compose commands live there rather
+  than in loose scripts. Commands run a handful of times a year are written
+  out in the README instead of earning a target.
 - **Image**: a two-stage `Containerfile`. `golang:1.27-alpine` compiles a
   static binary; the runtime stage is `FROM scratch` holding only that
   binary, running as UID 65534.
@@ -425,7 +430,7 @@ on the server and run with Docker Compose.
 - Pending migrations are applied on app start.
 - The Datastar client is vendored at `cmd/foodster/static/datastar.js` and
   served from the app's own origin — the SDK ships no browser asset, and a
-  CDN link would break an offline LAN. `make vendor` refreshes it; the pinned
+  CDN link would break an offline LAN. The README says how to refresh it; the pinned
   version lives in the `Makefile` and in the file's first line.
 - No internet exposure; the server binds to the LAN.