chore(base): Go 1.24.1 → 1.26 (build-time patch resolve), Node 22 → 24

[rappdw]

Both Go pins were on an EOL toolchain: Go supports only the two newest majors (1.25, 1.26), so 1.24 receives no security fixes. Node 22 is Maintenance LTS. This is PR-1 of a two-part toolchain refresh.

What changed

	Before	After
Go (base image)	ARG GO_VERSION=1.24.1	pins minor 1.26, resolves newest patch at build time
Go (egress proxy)	FROM golang:1.24-bookworm	FROM golang:1.26-trixie
proxy/go.mod	go 1.24.1	go 1.26.0
Node.js	NodeSource setup_22.x	setup_24.x

Why the base image now resolves at build time

The tarball URL (go.dev/dl/go<x.y.z>.linux-<arch>.tar.gz) requires a full x.y.z, so the base cannot float via the URL alone — but it can resolve one at build time. ARG GO_VERSION now pins the minor line and doubles as the offline fallback.

This is a response to measured behavior, not theory: ARG GO_VERSION=1.24.1 was introduced 2026-02-21 and never touched again — through 20+ releases (v1.0.0 → v1.5.0) at roughly weekly cadence, while Go shipped 1.24.2–1.24.13 and then two entire minors. A frozen pin's failure mode is human diligence, and the observed diligence was zero. Every other toolchain in this image (NodeSource, rustup … stable, Bun, uv) already resolves at build time; Go was the odd one out only because of the URL shape.

Hardened beyond the naive version: sort -rV | head -1 selects the max patch explicitly rather than inheriting go.dev's array ordering (which is newest-first only incidentally), and a non-numeric resolved value falls back to the pin instead of 404-ing the build.

Verified under real dash (Docker RUN uses /bin/sh, no pipefail) — both paths:

real go.dev:   resolved=1.26.5 chain_exit=0
dead endpoint: resolved=1.26.5 chain_exit=0

The proxy fix restores a mechanism that had gone quiet

golang:1.24-bookworm is a floating minor tag, so it genuinely delivered 12 patch releases (through 1.24.13, pushed 2026-02-04). But once 1.24 left the support window there were no further pushes, so from ~Feb 2026 the documented monthly-freshness + --pull mechanism (HF-incident Issue 3) re-resolved to an unchanged digest — refreshing Debian but not the Go stdlib that implements the proxy's TLS/HTTP/CONNECT I/O. Pinning a supported minor is what makes that mechanism work at all. CLAUDE.md's description is corrected to match this timeline.

Separately, proxy/go.mod is consumed by CI via go-version-file, so the proxy's vet/race/fuzz/govulncheck jobs had been running on an EOL toolchain too.

New test coverage

The base Go block had no guard at all. Added five, including a pin-must-be-a-supported-minor assertion that would have caught this exact rot (negative control: rejects 1.24.1, accepts 1.30.0), plus build-time-resolution, offline-fallback, max-patch, and non-numeric guards.

Scope

Debian bookworm → trixie and Python 3.11 → 3.13 are deliberately not here (they carry apt renames and a persistent-pip consequence) and follow as their own change. The proxy build stage moves to trixie ahead of the base image on purpose: it compiles a static binary into FROM scratch, so its build distro never reaches the runtime image.

Verification

Static (no Docker available in the authoring environment): bash -n, both doc-drift checks, §49 replayed standalone incl. the no-stderr heredoc regression check, generated Dockerfiles inspected for expansion artifacts, Appendix A confirmed byte-identical to the heredoc in the changed region. Externally verified: golang:1.26-trixie exists for amd64+arm64 and includes git (via buildpack-deps:trixie-scm); NodeSource node_24.x serves both arches; setup-go's index contains 1.26.0. go vet/build/test pass locally under an auto-downloaded 1.26.0 toolchain.

Not verifiable without a build — the main residual risk: that all four npm-installed agents behave under Node 24. CI's cache-miss --build-only plus a smoke launch settle it.

🤖 Generated with Claude Code