ci(release): build multi-arch docker images in the tag pipeline

[nullPointerEnjoyer]

What

The tag pipeline (release.yml) now produces multi-arch Docker images: it calls release_docker.yml twice (amd64 on the default runner, arm64 natively on ubuntu-24.04-arm with tag_suffix: arm64) and then assembles multi-arch manifest lists under the unsuffixed tags — no manual dispatches needed for a release.

How

• release.yml replaces the single build-docker call with build-docker-amd64, build-docker-arm64, and assemble-docker (assembly needs: both builds, runs assemble_manifests: true with the tag name as version).
• release_docker.yml declares its five inputs on the workflow_call trigger (previously inputs were dispatch-only, so caller-passed values would silently arrive empty), and both job gates are now purely ref-based: a called workflow inherits the caller's ref, so tag-pipeline calls pass the same protected-ref checks as manual dispatches. Any tag ref qualifies (release.yml's glob accepts bare X.Y.Z as well as vX.Y.Z; the grammar is validated and a leading v stripped before anything is pushed).
• Failure isolation: create-release deliberately does not depend on the arm64 build or the assembly. If either fails, the OS binaries and amd64 images still release; the arm64 half can be repaired by re-running the failed jobs or dispatching release_docker.yml from the tag ref.
• Concurrency: the two per-arch builds serialize behind the existing docker-release group; within one release run at most one job is ever pending in the group, so a single run cannot drop its own legs (the cross-run one-pending-slot caveat is documented on the build job).
• README: the multi-arch section now describes the automated flow and fixes a stale workflow filename.

Verification

• YAML structure assertions: needs-graph, inputs mirror, assembly with, and a behavior matrix of both job gates (tag/release/master refs build or assemble; feature branches and PR refs are skipped for both).
• All embedded run blocks pass bash -n.
• do_checks.sh exit 0; OCR review of the commit to 0 findings (the loop caught and fixed a silent no-op for bare-semver tags, an over-broad workflow_call bypass, and a comment overclaiming cancellation safety).

[github-actions]

🔍 OpenCodeReview found 2 issue(s) in this PR.

• ✅ Successfully posted inline: 1 comment(s)
• 📋 Routed to summary by policy: 1 comment(s)

---

📄 .github/workflows/release.yml (L167-L171)

⚠️ GitHub could not post this as an inline comment: Routed to summary (severity low · category maintainability)

The failure mode here (release shipped, assembly incomplete) is precisely the incident responders will need to act on, but the repair instructions exist only as stderr text in the run log. Consider appending a concise summary via $GITHUB_STEP_SUMMARY (or writing an artifact) so the repair recipe is visible on the run summary page and easy to copy, e.g. the exact gh workflow run commands for the arm64 build and assembly.

💡 Suggested Change

Before:

            if [[ "$RELEASE" == 'success' ]]; then
              echo "the release shipped amd64-only" >&2
              echo "repair by re-running the failed jobs of this run, or by dispatching release_docker.yml (platform=arm64, tag_suffix=arm64, runner=ubuntu-24.04-arm, then assemble_manifests=true) from the tag ref" >&2
              exit 1
            fi

After:

            if [[ "$RELEASE" == 'success' ]]; then
              echo "the release shipped amd64-only" >&2
              {
                echo "## Docker release incomplete (amd64-only)"
                echo 'Repair by re-running the failed jobs of this run, or:'
                echo '```'
                echo "gh workflow run release_docker.yml --ref ${GITHUB_REF_NAME} -f platform=arm64 -f tag_suffix=arm64 -f runner=ubuntu-24.04-arm"
                echo "gh workflow run release_docker.yml --ref ${GITHUB_REF_NAME} -f version=${GITHUB_REF_NAME} -f assemble_manifests=true"
                echo '```'
              } >> "$GITHUB_STEP_SUMMARY"
              exit 1
            fi