Stamp the container image so a rollout can be read back

[TennyZhuang]

Implements the instrument for task #97's container-side readback criterion.

The gap

The deploy passes --containers-rollout and prints the value in the job summary.
There is no container probe anywhere in the pipeline, so "the workflow went green"
has been the only evidence that a rebuilt image is serving — which is precisely
what the container readback criterion rules out. The criterion existed; the
instrument did not.

Shape

file	change
container/Dockerfile	ARG GIT_SHA → ENV BUILD_SHA
container/src/server.ts	/health reports build
worker/scripts/render-production-config.mjs	sets containers[].image_vars.GIT_SHA from GITHUB_SHA
worker/src/index.ts	GET /api/admin/container/build reads it back
.github/workflows/deploy-hands-server.yml	passes GITHUB_SHA explicitly

Why it is self-controlling

The image running in production contains no code that emits a build key.

key present  => the image was rebuilt and is serving   (the old image cannot fake it)
key absent   => the old image is still serving         (never "the probe missed")

So the next rollout is its own before/after control — no extra deploy is needed
to establish a baseline, and no deploy is being requested by this PR.

Decisions worth reviewing

Build-time, not runtime. A runtime value could only answer "some build made after
the instrument landed"; a build-time value answers which build. image_vars is
wrangler's build-arg channel — its own types say "available to the image at build-time
only" — and it exists in 4.105.0, the version the lockfile resolves and the deploy
uses. (Checked against 4.105.0 specifically: an unreferenced 4.118.0 also sits in the
pnpm store, and reading types from that one would have proven nothing about the deploy.)

ARG placement is load-bearing. GIT_SHA changes every deploy and an ARG
invalidates every layer below it. Declared beside the other ARGs it would rebuild the
Rust minidump-stackwalk, the apt layer, the Android SDK and npm ci on every deploy.
Placed after COPY src it invalidates two trivial lines, and COPY src already changes
whenever the source does.

No placeholder when unstamped. With GITHUB_SHA unset the renderer omits
image_vars entirely. A stamp that always carries some value cannot separate "built by
a deploy" from "built by hand".

Readback is admin-gated. The exact deployed commit narrows a public repository to
one revision for anyone asking which known issues apply, and this is run by operators.
It returns build: null with stamped: false rather than omitting the key, so a failed
read cannot be misread as an unstamped image.

Verification

• worker tsc --noEmit: 0 errors, against a 0-error baseline on clean main
  (the checked-out worker-configuration.d.ts was stale and failed identically on main;
  regenerated before comparing, so this is a like-for-like result)
• container npm run build (tsc --noEmit): 0 errors, baseline 0
• workflow lint: self-test 4/4, real files exit 0; environment: still bound
• renderer rendered both ways — the only diff is the image_vars block, and the
  no-SHA render contains 0 occurrences of image_vars/GIT_SHA

Not verified: the image build. No Docker on the machine I work from, so the
Dockerfile change is unbuilt. The two added lines are trivial syntax, but that is an
argument, not a test — worth a reviewer's eye.

Rollout

Rides the next natural container rollout. This PR requests no deploy.