Infra: Build and Tag Docker for PR's

This task is to complete the work required to enable seamless testing of sandboxed environments for every pull request, building upon the foundation laid in PR #1310.

#### The Problem

Testing the full, sandboxed functionality of the CLI from a pull request branch is currently difficult. There is no automated way to build or use a sandbox image that corresponds to the exact code in a PR. This forces developers to either test without the sandbox or perform complex manual steps, hindering our ability to validate changes thoroughly.

#### The Goal

Any pull request branch should be easily testable in its complete, sandboxed form. The end goal is to allow any contributor or reviewer to run `npx gemini-cli#` and have it automatically use a sandbox image that is built from and perfectly matches the code on that branch.

#### Recommended Implementation

This requires a two-part solution that connects our CI pipeline with the runtime logic of the CLI:

1. **CI Workflow for PRs:**
* The CI workflow that runs on pull requests must be enhanced to build the sandbox Docker image.
* This image must be tagged with the git commit SHA of the PR's head commit (``).
* The tagged image must be pushed to a shared, non-production container registry (e.g., a "dev" or "pr" repository in Google Artifact Registry or Docker Hub) where it can be pulled by testers.

2. **CLI Runtime Logic:**
* The build process for the CLI package must embed the git commit SHA into the package itself. The existing `scripts/generate-git-commit-info.js` script is a good starting point for this.
* The sandbox initialization logic (in `packages/cli/src/config/sandboxConfig.ts`) must be updated. When the CLI starts, it should read this embedded git SHA.
* Instead of using a static image tag, the sandbox logic will use this SHA to construct the full image name and pull the corresponding Docker image for the sandbox environment.

Completing this work, originally started in **PR #1310**, will create a powerful "preview" environment for every pull request, dramatically improving our testing capabilities and confidence in merges.

**Implementation Note:** To avoid code duplication, we should create a reusable GitHub Action for the logic of building and pushing the Docker image. This action can then be shared between this PR workflow and the main release workflow, ensuring consistency.