fix(agent-image): ship the uv binary in the runtime stage (#68)

[stubbi]

Second half of the #68 fix

#85 added pyproject.toml/uv.lock at /opt/venv-template/, which let init-uv get past its cp step — and immediately exposed a second latent defect in the same init container.

The conformance suite (un-skipped in #87, now that #85 republished the image) caught it:

pod/conformance-minimal-0   0/1   Init:Error   4 restarts
  init-uv  Terminated  Exit Code: 127
  logs init-uv: /bin/sh: 1: uv: not found

init-uv runs uv sync --frozen at pod start to materialise the env onto the per-instance PVC, but the runtime stage copies the resolved venv (/opt/venv) and never the uv binary. So uv sync → exit 127. Before #85, init-uv died at the earlier cp, masking this.

Fix

• COPY --from=uv /uv /uvx /usr/local/bin/ in the runtime stage (mirrors the builder).
• Deterministic UV_* defaults so the pod-start sync never downloads a Python or hardlinks across the image-layer → PVC boundary: UV_PYTHON_DOWNLOADS=never, UV_PYTHON=/usr/local/bin/python, UV_LINK_MODE=copy.

Verification (local)

Built the image and ran the exact init-uv command:

$ docker run --rm --entrypoint /bin/sh hermes-agent:uvtest -c \
    'set -eu; cd /home/hermes/.hermes; cp /opt/venv-template/{pyproject.toml,uv.lock} .; uv --version; uv sync --frozen'
uv version: uv 0.11.7
...
=== EXIT 0 ; .venv populated ===

Exit 127 → exit 0; .venv is created on the (PVC-equivalent) workdir.

After merge

Republish ghcr.io/paperclipinc/hermes-agent:v2026.5.29.2, then #87's conformance Idempotency job should go green and the un-skip lands.

Refs #68

🤖 Generated with Claude Code