feat(devcontainer): bake the rate-limit-fragile toolchain into a Dockerfile

[justinmerrell]

.devcontainer/ gains a Dockerfile and loses its compose file, so it now reads
image → environment → services:

.devcontainer/
  Dockerfile          bun, uv, task, mise as pinned ARGs
  .dockerignore       `*` — nothing is copied, and .env must not reach the daemon
  devcontainer.json   Features, mounts, env, ports, VS Code
  mise.toml           runtime-only CLIs
  scripts/
  stacks/
    compose.yaml      the orchestrator (moved from .devcontainer/)
    postgres/ redis/ minio/ registry/ azimutt/ observability/

Why the Dockerfile

bun, uv and go-task were Features. All three route through nanolayer's
gh-release installer, which lists a release's assets by calling
api.github.com with no credentials —
asset_resolver.py:126:

response = urllib.request.urlopen(
    f"https://api.github.com/repos/{repo}/releases/tags/{tag}"
)  # nosec

There is no Authorization header and no GITHUB_TOKEN read anywhere in that
module. Codespaces build hosts and GitHub-hosted runners share egress IP pools,
so the 60 req/hr anonymous limit is routinely exhausted, the call 403s, and one
failed Feature fails the whole image build — after which Codespaces drops the
developer into a bare recovery container showing task: command not found
rather than the real error.

Pinning does not help. The pin supplies the tag; _get_release_assets()
still calls the API to list assets. This was diagnosed downstream in
musher-dev/platform#1942; I re-verified every claim against upstream source
before porting it.

Two findings that differ from platform's write-up:

• go-task is exposed too, which platform missed — it uses the same
  nanolayer helper. platform doesn't pin that Feature, so it never surfaced there.
• The other third-party Features are clean and stay Features. deno and
  lukewiwa/shellcheck curl releases/download/... directly;
  robbert229/postgresql-client is apt. The rule is about the installer's
  behaviour, not the publisher.

mise is baked for a different reason: it was an unpinned
curl https://mise.run | sh in post-create — the only unpinned tool in a
template that pins everything else.

Deliberately not baked. The boundary is the Dockerfile bakes
version-pinned tools; post-create owns what is runtime or self-updating. In
particular mise install cannot run at build time — four of the six
entries in mise.toml use the npm:/pipx: backends, and Node and Python
arrive from Features, which layer after the Dockerfile stage.

Pins live in Dockerfile ARGs rather than a versions.sh (platform's
approach) because nothing else in this repo consumes them, and a third version
home would violate CONFIGURATION.md's "One need, one place". That also means
no COPY, so .dockerignore can be * and the gitignored .env never
reaches the daemon.

Why the compose move, and the trap in it

Moving the orchestrator to stacks/compose.yaml breaks Compose's positional
.env discovery, which resolves against the directory of the first -f file.
Left alone, the failure is silent — no error, just defaults. Measured on
this branch, same compose file:

	services resolved	POSTGRES_USER
with --env-file	10	proofuser (from the file)
without	1	postgres (default)

So every caller — startup.sh, the MOTD, and CI — now names the env file, and
the orchestrator pins name: musher-dev because Compose would otherwise derive
the project name from the stacks/ folder. .env.example's header, which
documented the old sibling contract, is updated to match.

Enforcement, not a comment

Re-adding one of those Features looks like a harmless simplification, so it is
a check. New toolchain policy (5th under .repo/):

Code	Enforces
TC-01	bun/uv/go-task must not appear in the features block
TC-02	every image-baked ARG is an exact pin, not latest
TC-03	TASK_VERSION matches CI's arduino/setup-task version

TC-03 replaces two hand-maintained "keep in lockstep with the go-task Feature
pin" comments that removing the Feature would have orphaned. The full
api.github.com diagnosis lives in the violation's reason, so it surfaces at
the point of failure.

scripts/verify-toolchain.sh replaces the build job's echo, asserting the
built container reports the pinned versions (the runtime half the Dockerfile's
presence-only test -x leaves open). It reads the pins back out of the
Dockerfile, so the ARGs stay the one source of truth.

Both ride existing CI jobs — no new job, so .github/rulesets/ and the
hooks policy are untouched.

Verification

Green: shellcheck (CI opts), markdownlint, yamllint, actionlint,
codespell, all five governance policies, and the full pre-commit hook set.
docker compose config resolves under default and all profiles, and each
stack's relative bind mounts (./init, ./config) still resolve against its
own folder rather than the orchestrator's.

Each TC-* code was negative-tested by sabotaging the file it guards.

Not run — no Docker daemon on the authoring host: the image build itself,
the docker run version assertion, and --frozen-lockfile. The lockfile was
edited by removing exactly the three dropped Features (11/11 parity with
devcontainer.json verified). These land with the first CI run; if the
Devcontainer Build or Devcontainer Lockfile job is unhappy, that is where
it will show.

Reviewer notes

• Worth a look: Dockerfile (the rationale header is the point of the file),
  policies/toolchain/violations.py, and the --env-file threading.
• Unrelated pre-existing bug left alone: post-create.sh:39 gates lefthook
  installation on a root lefthook.yml that config/check.py:94 forbids, so
  git hooks are never installed by post-create.
• CONFIGURATION.md's "Runtimes & Tools" goes from three tiers to four; the
  decision tree and quick reference follow.

🤖 Generated with Claude Code