feat(docker): the Harness images carry the GitHub CLI #288

Problem

A coding agent in a workspace Session works in its clone with git and the provider's CLI, as a person does on a laptop: it fetches, branches, commits, pushes, opens and reads pull requests. The Go ADK runtime image (go/Dockerfile) installs bash, ca-certificates and git, and the Claude harness image (go/harness/claude/Dockerfile) installs git and ripgrep; neither carries gh, so gh pr create, gh pr view or gh run list cannot run in a Session's sandbox on either Harness. The agent is left to hand-craft API calls or fails the task.

Proposed solution

Both images install the GitHub CLI from Alpine's github-cli package, pinned to one version in a build argument shared by the two Dockerfiles, for amd64 and arm64. No credential is baked in and none is configured: gh authenticates with whatever GH_TOKEN the runtime hands it, and in a workspace Session that is an inert placeholder the egress gateway replaces with the person's token (the caller credential mechanism of #147, selected per Session). The change is one carried commit on the fork line, recorded in FORK.md, and offered upstream as the Go ADK's and the Claude harness's Dockerfile change; if upstream declines it for the Go ADK image, the row becomes fork-only and says so.

Acceptance criteria

• gh --version and git --version succeed through the bash tool in a Session's sandbox on the kagent Harness and on the claude Harness (fork e2e, both image architectures)
• image-scan is green for both images and the PR states each image's size growth
• The github-cli version is pinned once and Renovate (renovate.json5) tracks it
• FORK.md row with the upstream pull request, or the fork-only verdict