Fix rotted gh CLI pin in MicroVM image Dockerfile

[frederiksally]

The Lambda MicroVM agent image fails to build for every new AWS deployment: the
Dockerfile pins gh-2.96.0-1 from cli.github.com's rpm repo, but that repo keeps
only the latest gh release. 2.96.0 was removed when 2.97.0 shipped, so
dnf install -y gh-2.96.0-1 fails with "No package matches 'gh-2.96.0-1'".

qm infra build-image then dies on the AWS side as a bare
The container image build failed. (CREATE_FAILED on the image version) with no
exported build logs, which makes the rot look like an account/permission problem
until the Dockerfile is built locally.

Install the repo's current gh release instead of pinning. The repo config stays
gpgcheck=1, so packages remain signature-verified; pinning a minor version in a
single-version repo re-breaks on every gh release.

Both copies of the template are updated (aws/microvm-agent/Dockerfile and
cli/templates/aws/microvm-agent/Dockerfile).

Verified by building the image locally against the pinned base
(public.ecr.aws/lambda/microvms:al2023-minimal@sha256:05cb9b38d841e7ff1b693dc9e894909612f340bf99ec97d426e8000a5bbe96c3):
before, the build fails at the gh install step; after, the full image builds cleanly.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[time-attack]

Thanks for this, @frederiksally — and sorry for the slow response.

We're closing this PR. Per CONTRIBUTING.md, since coding agents write most of the underlying code now, we'd rather receive feature ideas as a short human-written note in adrs/ — informal is great, just the idea in your own words — and bugs as a plain issue. If we're aligned we're happy to burn our own tokens on the implementation, and we'll credit you as co-author.

We don't want your idea to get lost, so we've captured it in #834 to triage on our side. Please feel free to open an adrs/ note if you feel strongly about the approach. Appreciate you engaging with the repo!