fix: publish release artifacts after successful image retagging

[n30nex]

Successful release fast paths publish image tags but never dispatch the job that creates the GitHub release and decrypt binaries. Dispatch deploy.yml from both image routes. A default-off images_published input skips E2E and image rebuilding only for an already-published tag; missing or mismatched images keep the complete fallback without requiring new inputs on older workflow definitions.

Go validation still gates the release binaries, checkout and version flags retain the tagged source, and the existing release action uploads both architectures before publication. Missing binary files now fail publication.

Fixes #1956.

Validation:

• node test-issue-1956-release-routing.js executes the actual workflow shell steps with registry and dispatch commands stubbed. Covers matching, missing and mismatched images; failed retag and Go validation; branch/PR boundaries; and both tagged binary commands.
• The original test commit fails because a matching image dispatches zero artifact workflows; the fix passes the same assertion.
• Existing release workflow Go checks, decrypt/channel tests, YAML parsing and actionlint pass.
• Both static Linux amd64 and arm64 binaries cross-build with verified architecture and version metadata.

Actual registry publication and GitHub release creation were not exercised. Existing immutable releases and old tags that contain older workflow definitions are outside this fix.

Following #1922, this is a focused release-routing PR. A separate repair for #1858 rewrites the shared frontend test runner; merging this first lets that repair retain this regression in its authoritative list. Please assess current Go and E2E job results separately from workflow-approval or staging-runner state.

[efiten]

Reviewed. This closes #1956 correctly and I could not find a hole in it. CI had never run on any of your seven PRs (they were sitting in action_required); I have approved all of them, so real runs are coming now.

I filed #1956 after asserting, wrongly and repeatedly, that pushing a tag made deploy.yml create the release. It does not, and your diagnosis of why is exact: deploy.yml triggers on push: branches: [master], pull_request and workflow_dispatch, with no tags: anywhere, while release-fast-path.yml is the only thing listening on v[0-9]+.[0-9]+.[0-9]+. So the fast path retagged images and nothing ever created the release.

Checked rather than read:

The workflows still load. Both parse clean with a duplicate-key-detecting loader, deploy.yml yielding 7 jobs. That matters more than it sounds here: a duplicate mapping key makes GitHub reject the whole file and produce a run with zero jobs, which looks like "CI did not trigger" rather than an error. I lost a day to exactly that on this file.

My first pass at this check reported 68 duplicate keys and was wrong: my detector counted uses and run across separate list items as collisions. The file is fine; the detector was not.

The gating cannot silently skip the normal paths. !(startsWith(github.ref, 'refs/tags/v') && inputs.images_published) is on build-and-publish and release-artifacts. On push and pull_request the inputs context is empty, so the term is falsy and the jobs run.

The release can actually be created. Top-level permissions are contents: read, which would have made the whole thing fail at the last step. release-artifacts carries its own permissions: {contents: write}, so it is fine. Worth stating explicitly since the PR body says release creation was not exercised.

Your test runs. node test-issue-1956-release-routing.js: 4 PASS, covering matching, missing and mismatched :edge, plus the failure and branch routes.

The subtle part is right, and it is the part I would have got wrong. Not passing --field images_published=true on the mismatch route, because workflow_dispatch --ref <tag> runs the workflow file from that ref and an older tag's deploy.yml has no such input. The comment says so in two lines. That is the kind of thing that fails once, in production, six months from now.

fail_on_unmatched_files: true and the "keep one writer, published releases are immutable" comment are both the right instinct. This repo has immutable releases enabled and a burned version number to prove it: deleting a published release does not free its tag, so a half-written release cannot be cleaned up and redone under the same name.

What nobody can verify from a PR: the happy path only proves itself when a real tag is pushed. Given the immutability above, the first release after this merges is worth watching live rather than firing and walking away. Not a change request, just where the risk actually sits.

Waiting on the CI run I just unblocked; assuming it comes back green this is good to merge.

[efiten]

Merging, ahead of #1965 as you suggested, so that one can rebase onto the final shape of test-all.sh rather than the other way round.

Full review is in my earlier comment. Nothing has changed since except that master has moved under it by seven commits; it still applies cleanly.