chore(deps): docker: bump mise digest and golang 1.26.4 to 1.27.1

[isadeks]

Supersedes the safe portion of #827. Related: #871.

Change

Two of #827's three base-image bumps, byte-identical to that PR (verified by diffing agent/Dockerfile lines 22 and 25 against refs/pull/827/head):

jdxcode/mise:latest   digest refresh only, tag unchanged
golang                1.26.4-bookworm -> 1.27.1-bookworm

The golang bump affects only the gh-builder stage, which compiles the gh CLI and is then discarded, so it cannot reach the runtime image.

What this deliberately leaves behind

agent/Dockerfile:29   python:3.13-slim -> python:3.14-slim

build (agentcore) is green on #827, so that bump does build and the suite does pass — this is not a claim that it is broken. The problem is that it moves the agent's runtime interpreter while three other places still say 3.13:

• agent/mise.toml:4 — python = "3.13", so local development and the container would run different minors.
• agent/pyproject.toml:184 — python-version = "3.13" is the ty/ruff target, so type-checking would no longer describe the runtime. (requires-python = ">=3.13" at :5 does permit 3.14, so that one is not violated.)
• agent/Dockerfile:44 — the CVE-patching comment names the python:3.13-slim tag explicitly, and would become a false reference in the same commit.

For a dependency set this C-extension-heavy (pydantic, boto3, the OpenTelemetry distro), an interpreter bump is worth validating on its own and landing together with those three pins. #871/#872 adds a dependabot ignore for python major/minor on the docker ecosystem so it always arrives as its own reviewable change, while digest and patch refreshes keep flowing.

Testing

Correction to an earlier version of this description: it claimed CI's build (agentcore) builds the image. It does not. There is no docker build in any workflow (grep -rn "docker build\|buildx\|DockerImageAsset" .github/workflows/ is empty); build.yml runs mise run build, whose DAG never realises the DockerImageAsset, and the only task that builds this Dockerfile — //agent:security:image (agent/mise.toml:61) — is reachable solely from mise run security in security.yml, which is workflow_dispatch + a Monday 0 12 * * 1 cron. So green checks here are not evidence for a base-image change. That observation is due to the standing review on #827 (its B2); I verified it independently before relying on it.

So I built and scanned it locally instead — both halves of //agent:security:image, on linux/arm64.

Build: succeeds. Verified by artifact rather than exit code:

python3 --version    Python 3.13.13      <- interpreter NOT bumped
go version (builder) go1.27.1 linux/arm64 <- the bump took effect
gh --version         gh version 2.93.0
mise --version       2026.9.1 (2026-09-02) <- the new digest
claude --version     2.1.191 (Claude Code) <- #215 lockstep intact

go is absent from the final image, confirming the gh-builder stage is discarded as claimed; the toolchain version above comes from --target gh-builder.

Trivy: this is the part worth reading. I scanned an image built from clean upstream/main and one from this branch with the task's exact flags, and diffed the HIGH/CRITICAL sets:

main:     23 findings
this PR:  14 findings
new:       0
fixed:     9

All 9 are Go stdlib CVEs in usr/local/bin/gh — CVE-2026-33818, -39821, -39822, -46600, -56853, -56858, -56859, -56860, -56862 — cleared because gh is now compiled with go1.27.1 instead of 1.26.4. That is precisely the rationale the Dockerfile gives at line 24 for building gh from source rather than taking a distro package, so this bump is doing the job it exists to do.

Note the scan exits 1 on both images: 14 findings remain on this branch (gh's Go module dependencies, four Node packages, and quinn-proto in uv), all pre-existing on main and none introduced here. Worth a separate look, since it means the Monday security cron is currently red.

Follow-up

#827 stays open until #872 merges, then it can be closed — with the PR limit still at 1 and no python ignore in place, closing it today just returns the same three-way group on the next Saturday run. Same sequencing as #859 and #860.

The Python 3.14 migration already has an issue — #105 — which is open and not yet approved. Per the #827 review it also needs two checklist items it currently omits: agent/mise.toml:4 and agent/.python_version.

CI note

Secrets, deps, and workflow scan is red, and not because of anything here — this PR does not touch yarn.lock. osv-scanner reports the same 7 advisories across 5 npm packages on this branch as on main: astro ×2 (incl. GHSA-26w7-cxv4-gfx2 at 9.8), js-yaml, sharp, smol-toml, and svgo ×2. Every branch cut from main inherits them, which is what #870 ("clear 7 osv advisories blocking the merge queue") exists to fix. #870 is already approved; once it merges, rebasing this should turn the check green.