Build the Docker image with a separate Dockerfile ref

[fnando]

What

Decouple the Dockerfile/build recipe from the source revision in the Docker workflow. A new dockerfile_ref input (default main) controls where the Dockerfile comes from, independent of the ref being compiled. The prepare job now resolves both refs to immutable SHAs and outputs source_sha, dockerfile_sha, and the tags; build checks out dockerfile_sha while passing source_sha to cargo install --git … --rev; and merge checks out dockerfile_sha.

Why

After #2605 the build checked out the source ref to obtain the Dockerfile, so dispatching with a ref that predates the current Dockerfile — e.g. an existing release tag like v26.1.0 — failed because the checked-out tree still had the old COPY-based recipe. Separating the two refs lets an old release tag be built with the current recipe, which is the whole point of installing the CLI from --git … --rev. Resolving both refs to SHAs once also keeps every architecture and the published manifest consistent.

Known limitations

The Dockerfile ref defaults to main, so dispatching against a branch whose recipe has not been merged still requires passing dockerfile_ref explicitly. This workflow remains a temporary measure until stellar/stellar-cli-docker publishes images.

[Copilot]

Pull request overview

Decouples the Docker workflow’s build recipe (Dockerfile) from the source revision being compiled, so older release tags can be built using the current Dockerfile while still compiling the CLI at the requested source ref.

Changes:

• Adds a new dockerfile_ref workflow input (default main) separate from the source ref.
• Updates the prepare job to resolve and output both immutable SHAs (source_sha, dockerfile_sha) and compute tags from the source ref.
• Updates build/merge to check out the Dockerfile SHA while passing the source SHA into the Docker build as STELLAR_CLI_REV.