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.

docs/operations/backup-and-restore.md

@@ -40,6 +40,13 @@ nobody can read.
   reconnect on their own, because `servers.agent_token_hash` — the thing an
   agent authenticates with — is itself in the backup.
 
+:::note Pin the version
+The image is published on each `vantagectl/v*` release and tagged with that
+version; `:latest` also moves. Pin a version in anything scheduled. A restore
+is easier to reason about when you can say which build produced the archive and
+which one read it back.
+:::
+
 ## Taking a backup
 
 The loose binary:
@@ -59,7 +66,7 @@ docker run --rm \
   -e MONGO_DB=vantage \
   -e KEY_ENCRYPTION_KEY=<your 64-char hex key> \
   -v /backups:/backups \
-  gitea.hostxtra.co.uk/mrhid6/vantage/vantagectl:latest backup --out /backups
+  gitea.hostxtra.co.uk/mrhid6/vantage/vantagectl:0.1.0 backup --out /backups
 ```
 
 Kubernetes, as a scheduled `CronJob` the Helm chart can render for you:
@@ -68,7 +75,7 @@ Kubernetes, as a scheduled `CronJob` the Helm chart can render for you:
 backup:
   enabled: true
   schedule: "0 2 * * *"
-  image: "gitea.hostxtra.co.uk/mrhid6/vantage/vantagectl:latest"
+  image: "gitea.hostxtra.co.uk/mrhid6/vantage/vantagectl:0.1.0"
   pvcName: "vantage-backups"
 ```