Publish release images by dispatch, built from the tag (#823)

Publishing the 9.7.0 GitHub Release produced no workflow run at all - not a failed
one, nothing - and the images were never pushed.

GitHub runs a release event's workflow as it exists at the tag, not as it exists on
the default branch. The v9.7.0 tag was cut on 12 Aug and the release trigger landed
on main the next day, so GitHub read the tag's copy of publish-docker.yaml, found
no release trigger, and correctly did nothing.

That is not a one-off. The tag is cut at `prepare` and the Release is published at
`vote-passed`, at least 72 hours later, so anything changed in this workflow inside
that window silently does not apply to the release in flight. The window reopens
every release; 9.7.0 was just the first time something landed in it.

Drop the release trigger and dispatch instead. `github-release` creates the Release
and then runs `gh workflow run publish-docker.yaml -f version=x.y.z`, so publishing
stays automatic rather than becoming something to remember, and there is one path
rather than two that could both fire. A dispatch always runs the workflow from the
default branch, which makes what publishes a function of main rather than of when
the tag happened to be cut. If the dispatch fails the Release is already out, so
the script warns with the retry commands instead of aborting.

Everything the run acts on still comes from the tag rather than from a branch or a
timestamp. The tree is checked out at refs/tags/vx.y.z, so Dockerfile and Makefile
- which decide what the image actually is - come from the released source instead
of from whatever main looks like now; without that a dispatch would have built with
main's copies. The agent package remains the sha512- and signature-verified tarball
from dist/release, and the image tags come from the version. A leading v on the
input is tolerated, and leaving it blank builds a development image exactly as a
push to main does.