test(scaffold-e2e): cover the pinned Dockerfile shape a real scaffold ships

[os-project-manager]

Fixes #9117

The docker leg of scaffold-e2e scaffolds with --skip-install and installs the generated project in a separate step, so the scaffolder's own post-install work never runs — and the Dockerfile runtime-image pin landed by PR #9115 (for #9017) lives exactly there. The shape the job built and booted was therefore the unpinned one (FROM ghcr.io/objectstack-ai/objectstack:latest), while every real npx create-objectstack user ships the pinned one. The pin silently ceasing to happen was invisible to this job.

This lands the card's first shape: a second, throwaway project scaffolded the way a real user does — no --skip-install — asserting only that the emitted Dockerfile names the @objectstack/cli version the project actually resolved. No docker build: the two shapes differ by exactly one FROM tag, and the existing leg already proves the image builds and boots. Option 2 (relocating the install into the scaffolder) was not taken and no impracticality is claimed — see the residual at the bottom.

What only this leg can catch

runtime-image.test.ts covers the rewrite on fabricated input. What needs an end-to-end run is the pin never running: a scaffolder that stops calling it, or an install path that no longer leaves a resolvable CLI behind. Both are proven discriminating below.

The three branches, all measured

The step distinguishes two failure classes rather than skipping on any install trouble. When the scaffolder's install leaves no CLI behind, the registry is asked whether the emitted range was satisfiable at all:

Situation	Verdict
pin ran	green — FROM tag == resolved CLI
pin did not run, CLI resolvable	red, naming the pin
install left no CLI, range unsatisfiable	warn + skip (the unpublished-version window)
install left no CLI, range satisfiable	red — the scaffolder's install path is broken

Verification — union run at d1ae6ce7e, the final commit

CI cannot be run locally, so every run below executes the literal run: block extracted out of scaffold-e2e.yml by a small YAML harness, with RUNNER_TEMP / GITHUB_WORKSPACE set — the bytes CI will run, not a re-typed copy. The workflow invokes bin/create-objectstack.js, which resolves dist/, so every ablation was rebuilt and its arrival in the artifact proven with scripts/ablation-dist-preflight.mjs before the run's colour was allowed to mean anything.

Green, unmodified scaffolder:

resolved @objectstack/cli   : 17.0.0
emitted Dockerfile FROM tag : 17.0.0
pinned as expected: FROM tag == resolved CLI (17.0.0)
STEP EXIT=0

Reverse verification (direction predicted before running: red in the first two, exit 0 in the third, red in the fourth):

Ablation	dist preflight	Result
pinRuntimeImage returns success without writing	marker present	red — see message below
the pin call removed from index.ts wiring	call-site marker absent	red, identical message
scaffolder version bumped to an unpublished 99.0.0	n/a (runtime read)	exit 0 + ::warning:: — the window branch
detectPackageManager returns a broken pm	marker present	red — install-path branch

The red message names the pin, which is what the card asked for:

::error::the scaffolder did NOT pin the Dockerfile runtime image: the emitted
FROM tag is 'latest' but this project resolved @objectstack/cli@17.0.0. This is
the file every real npx create-objectstack user ships (#9017); the
--skip-install legs in this job cannot see it.

Worth recording: under ablation 1 the scaffolder still printed its own ✓ Dockerfile runtime image pinned to 17.0.0 while the file was untouched — the exact "silently not happening" mode, and the reason a leg that reads the emitted file is the only thing that catches it.

Restore legs: index.ts's call-site marker was proven present again after ablation 2, no ABLATION_9117 string survives in src/ or dist/, the working tree is clean at d1ae6ce7e, and pnpm --filter create-objectstack test is 58 passed (4 files) from the restored tree — this PR changes no package source.

Gates re-derived against the actual changed path (.github/workflows/scaffold-e2e.yml), which added nothing beyond the dispatched list — all green at d1ae6ce7e: check:node-version, check:required-contexts, check:shard-attestation, check:workflow-status-functions, check:nul-bytes, node scripts/check-shard-attestation.mjs. Control-byte self-scan of the edited file: clean.

The comment that had gone stale

The docker leg claimed to exercise "the exact Docker path a real npm create objectstack user ships" — true only of the --skip-install variant since PR #9115. It now states its scope precisely and points at the new step for the pinned half. The file header gained the same split.

Residual, stated rather than hidden

In the unpublished-version window the new leg warns and skips instead of asserting. That is not a design preference: the fallback which rewrites unresolvable @objectstack/* ranges to latest lives in the workflow's install step, and relocating it into the scaffolder is the separate design the card records. The degradation is evidenced (the registry is asked) rather than blanket, so a broken install path still fails loudly. That fork needs a card of its own; out of scope here, and no other card is addressed by this PR.

Changeset

None — .github/workflows/** only, releasing nothing user-visible. skip-changeset applies.

---

Generated by Claude Code