ci: move the galactus deploy chain to a tag-only workflow

The deploy was a job inside build.yml gated by
`if: startsWith(github.ref, 'refs/tags/v')`. Gitea draws every job into the
run graph before it evaluates that `if`, so an ordinary push to master showed
a pending "Deploy to galactus" — indistinguishable from prod being about to be
redeployed off an unreleased commit, and the only safe reaction is to cancel
the run, which takes the images down with it.

The gate itself was never wrong (no deploy-galactus run has ever been created
from a branch ref), but a guarantee you cannot see is not much of a guarantee.
`on: push: tags: ["v*"]` in a workflow of its own makes it structural: the
deploy cannot appear on a master build because the workflow does not exist
there.

It replaces `needs: build` by polling the Actions API for the build.yml run at
this tag and requiring it green, so both images are still known to be in the
registry before anything is pulled. AUTO_DEPLOY_GALACTUS still cuts the chain.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

.gitea/workflows/release.yml

@@ -1,14 +1,16 @@
 # Cut a release: stamp the version across every package.json, commit, tag, push.
 #
 # This does NOT build and does NOT deploy itself. Pushing the `vX.Y.Z` tag is
-# what triggers build.yml, which publishes `X.Y.Z`, `X.Y`, `sha-<short>` and
-# `latest` image tags — and then, on a green tag build only, dispatches
-# deploy-galactus.yml with `tag=X.Y.Z scope=app` (no leading v — the git tag
-# carries the `v`, the image tag does not).
+# what triggers both build.yml, which publishes the `X.Y.Z`, `X.Y`,
+# `sha-<short>` and `latest` image tags, and deploy-on-tag.yml, which waits for
+# that build to go green and then dispatches deploy-galactus.yml with
+# `tag=X.Y.Z scope=app` (no leading v — the git tag carries the `v`, the image
+# tag does not). A tag is the only ref that starts either chain; pushing to
+# master builds images and stops there.
 #
 # So cutting a release DOES reach prod. To cut a version without deploying it,
-# set the repo variable AUTO_DEPLOY_GALACTUS=false first; build.yml's `deploy`
-# job then prints the manual command instead of running it.
+# set the repo variable AUTO_DEPLOY_GALACTUS=false first; deploy-on-tag.yml then
+# prints the manual command instead of running it.
 #
 # Why a workflow instead of three local commands: the release commit is the one
 # thing that must be identical every time, and cutting it from a laptop is how
@@ -270,8 +272,8 @@ jobs:
           echo "Released v${VERSION}."
           echo ""
           echo "build.yml is now building git.mancinas.io/rmancinas/jorgecuadros-{api,web}:${VERSION}."
-          echo "When both images are pushed, build.yml dispatches 'Deploy to galactus'"
-          echo "automatically with tag=${VERSION} scope=app bootstrap=false skip_migrate=false."
+          echo "deploy-on-tag.yml is watching that build; when it goes green it dispatches"
+          echo "'Deploy to galactus' with tag=${VERSION} scope=app bootstrap=false skip_migrate=false."
           echo ""
           echo "Watch that run. If it did not start (or AUTO_DEPLOY_GALACTUS=false),"
           echo "dispatch 'Deploy to galactus' by hand with the same inputs."