ci: bind docker/pypi workflow inputs via env before shell

[SashaMIT]

Summary

• Bind inputs.platforms-to-build through env: before the docker-build matrix plan shell step.
• Bind dh-repository-owner / version / push-latest through env: before docker-publish tag construction.
• Bind inputs.dist-location through env: before the pypi-publish shell step.
• Same class as GitHub’s documented script-injection guidance for interpolating workflow inputs into run: scripts.

Test plan

• Docker build matrix still parses comma-separated platforms
• Publish still creates version/latest tags for trusted inputs
• PyPI publish still honors optional dist-location

Changelog-None

Made with Cursor

[cdecker]

ACK 6d318d0

[Andezion]

The same vulnerable pattern - raw ${{ inputs.version }} / ${{ github.ref_name }} interpolated directly into run: - still exists, untouched, in the workflows that feed these three:

1. check-release-tag.yml at line 34 - echo "version=${{ inputs.version }}" >> "$GITHUB_OUTPUT", and line 44 TAG_VERSION="${{ github.ref_name }}", and line 56 tools/check-release.sh --version=${{ steps.resolve.outputs.version }}
2. release-build.yml at line 44-45 - if [[ "${{ inputs.skip_validation }}" == "true" ]] and --force-version "${{ inputs.version }}"
3. release-publish.yml at line 54 - VERSION="${{ inputs.version }}", the exact pattern this PR fixes elsewhere
4. pypi-build.yml at line 38 - make update-pyln-versions NEW_VERSION=${{ inputs.version }}

Do you plan a follow-up pr for check-release-tag.yml/release-build.yml/release-publish.yml/pypi-build.yml, or was leaving them out intentional?

[SashaMIT]

Good catch @Andezion, follow-up opened: #9388 covers all four workflows you listed (check-release-tag, release-build, release-publish, pypi-build) with the same env-binding pattern. Kept it as a separate PR so this one's approval stays clean.

[cdecker]

ACK 567cb8d