Eliminate stale deployable artifacts and enforce cross-plane release parity

[jmcte]

Finding

Deployable artifacts do not share one release version or one canonical rendering contract:

• package.json and config/pools.yaml use 0.2.1.
• config/linux-docker-runners.yaml still uses 0.1.9.
• The tracked default docker-compose.yml still uses 0.1.9 and materially differs from a fresh render.

A fresh render also changes storage roots (/volume2 to /volume1), GitHub App environment support, fleet labels/metadata, and the selected public-repository list. No test compares the tracked default file with canonical config.

Impact

The default docker compose up path and the advertised Linux Docker install path can deploy obsolete runtime, authentication, routing, and storage policy even while release checks pass.

Recommended work

• Decide whether docker-compose.yml is a canonical deployable artifact or generated output.
• If generated, stop tracking it or enforce exact regeneration parity in CI.
• Move every deployable plane to a single image-version source of truth.
• Extend the release contract beyond config/pools.yaml to Linux Docker and any project-owned Windows image.

Acceptance criteria

• A clean canonical render has no diff against any tracked generated artifact.
• All production/default plane configs use the verified current image version.
• CI fails when a deployable config or generated manifest drifts.
• Documentation identifies generated examples clearly and avoids making stale files Docker defaults.

Evidence

• package.json:3
• config/pools.yaml:2-4
• config/linux-docker-runners.yaml:2-4
• docker-compose.yml:1-6
• test/release-contract.test.ts:7-20