fix: pin Deno Docker image and pass release version via job outputs

[stack72]

Summary

• Pin Dockerfile base image to denoland/deno:2.7.5 instead of :latest for reproducible, deterministic builds
• Pass version via job outputs from the release job to the docker job instead of querying gh release view, which could theoretically return a different release

Impact

These changes make the release pipeline more deterministic:

1. Reproducible Docker builds — Pinning the Deno base image means the same Dockerfile produces the same image regardless of when it's built. Previously, :latest meant builds could silently pick up a new Deno version with breaking changes or security issues.

2. Correct version propagation — The docker job now receives the exact version from the release job that created it via needs.release.outputs.version. Previously, gh release view returned the repo's latest release, which could be wrong if a manual release was created between jobs.

Why this is correct

• The release job already computes the version in the version step — we simply expose it as a job output
• The docker job already declares needs: release, so the output is guaranteed to be available
• No behavioral change in the happy path; this only eliminates edge-case failure modes

Addresses review feedback from #882.

Test plan

• Verify CI passes on this PR
• Confirm release workflow still builds and pushes Docker images correctly on next merge

🤖 Generated with Claude Code

[github-actions]

Code Review

Blocking Issues

None.

Suggestions

None — this is a clean, focused improvement.

Review notes:

1. Pinned Docker base image (denoland/deno:2.7.5): Correct approach for reproducible builds. The team should remember to bump this periodically as new Deno versions are adopted.

2. Version passthrough via job outputs: The release job already computes the version at steps.version and the docker job declares needs: release, so needs.release.outputs.version is guaranteed to be available. This eliminates the race condition where gh release view could return a different release.

3. Security: The version is passed through the RELEASE_VERSION env var rather than direct ${{ }} interpolation in the run: block, which is the correct pattern for avoiding script injection.

LGTM — ship it.

[github-actions]

CI Security Review

Critical / High

None.

Medium

None introduced by this PR. Pre-existing: third-party actions (softprops/action-gh-release@v2, peter-evans/repository-dispatch@v3, docker/*@v3/v6, denoland/setup-deno@v2) use tag pins instead of SHA pins. This is outside the scope of this PR.

Low

None.

Verdict

PASS — Both changes are security-positive. The Dockerfile pins denoland/deno to a specific version (eliminating latest tag drift), and the workflow replaces a dynamic gh release view lookup with a deterministic job output, removing a potential race condition and reducing the blast radius of the GH_TOKEN in the docker job.