fix: Build the vantagectl image on its release tag, not on every push to main

vantagectl is a released tool, not a running service. An operator restoring a
database should be able to name the version they ran, and ":latest, rebuilt
whenever main moved" cannot be named after the fact.

The image now builds in vantagectl-release.yml on a vantagectl/v* tag, tagged
with that version as well as latest, with VERSION passed through so the binary
inside reports the tag rather than "dev". server-deploy.yml no longer builds
it and is back to seven images.

The cost is that a shared/ fix reaches the image only at the next release
rather than the next push to main. That is the intended trade and is written
down in CLAUDE.md next to the trigger table.

CLAUDE.md

@@ -657,8 +657,11 @@ temporary directory before verifying its checksums, and a scratch image has no
 `server`, but here it would break every restore rather than only vulnerability
 scanning.
 
-**`shared/` now fans out to four Go images** in `server-deploy.yml`:
-`server`, `sitesvc`, `admin` and `vantagectl` — see the CI section below.
+**`shared/` reaches four Go images, but only three of them from
+`server-deploy.yml`** (`server`, `sitesvc`, `admin`). The `vantagectl` image is
+built by `vantagectl-release.yml` on a `vantagectl/v*` tag instead, so a
+`shared/` change reaches it at the next release rather than the next push to
+main — see the CI section below.
 
 ### API tokens and OpenAPI
 
@@ -1318,7 +1321,7 @@ GOOS=linux GOARCH=amd64 go build \
 
 ### `server-deploy.yml` — triggered on every push to `main`
 
-Builds and pushes eight images to the Gitea container registry: `server`, `web`, `site`, `sitesvc`, `admin`, `adminsite`, `docsite` and `vantagectl`.
+Builds and pushes seven images to the Gitea container registry: `server`, `web`, `site`, `sitesvc`, `admin`, `adminsite` and `docsite`. **`vantagectl` is deliberately not among them** — it is a released tool rather than a running service, and its image is version-tagged by `vantagectl-release.yml`.
 
 Note that despite the name, **this workflow does not deploy** — it only builds and pushes. There is no SSH step. Rolling images out is a separate manual step on the host:
 
@@ -1334,13 +1337,16 @@ cd /opt/vantage && docker compose -f docker-compose.yml -f docker-compose.site.y
 | `server`                     | `server/`, `shared/`, `proto/`, `go.work` |
 | `admin`                      | `admin/`, `shared/`, `go.work`            |
 | `sitesvc`                    | `sitesvc/`, `shared/`, `go.work`          |
-| `vantagectl`                 | `vantagectl/`, `shared/`, `go.work`       |
 | `web` · `site` · `adminsite` · `docsite` | their own directory only      |
 
-`shared/` fans out to **four** Go images (`server`, `sitesvc`, `admin`,
-`vantagectl`) because each of their Dockerfiles copies `shared/` from a root
-context — **if a fifth service ever imports `shared/`, add it to that list or
-it will ship stale**. A change to the workflow file rebuilds everything, since
+`shared/` fans out to **three** images here (`server`, `sitesvc`, `admin`)
+because each of their Dockerfiles copies `shared/` from a root context — **if a
+fourth service ever imports `shared/`, add it to that list or it will ship
+stale**. `vantagectl` also imports `shared/` and is the exception: it is built
+by `vantagectl-release.yml`, so a `shared/` fix reaches it only when someone
+cuts a `vantagectl/v*` tag. That is deliberate — an operator restoring a
+database should be running a version they can name — but it does mean a
+`shared/backup` fix is not live until it is released. A change to the workflow file rebuilds everything, since
 a build arg is baked into the image. So does anything that leaves no
 trustworthy base commit: a manual `workflow_dispatch`, a new branch, or a
 force-push whose old head is gone.