[Fix] Publish GHCR Images fails deployment acceptance without Docker disk quotas

[roomote-roomote]

Created by Roomote. Follow up by mentioning @openmote, in the web UI, or in Slack.

What changed

Deployment acceptance opt-ins to the documented unbounded-disk escape hatch so the Publish GHCR Images gate can still launch Docker workers on acceptance runners. Production compose and env defaults stay fail-closed when storage drivers cannot enforce the writable-layer limit. A deployment-artifact check keeps that CI opt-in from being dropped accidentally.

Why this change was made

After the Docker sandbox hardening in #109, Publish GHCR Images on develop failed Deployment acceptance (amd64) because the CI host storage driver cannot enforce the 20g writable-layer quota. Acceptance never opt-ed into the intended override, so launch-docker-task refused to start workers and image publish stayed blocked.

Impact

No product UI change. Deployment acceptance and GHCR publish on develop can proceed again on hosts without quota-capable Docker storage. Self-hosted and production Docker deployments keep the default refuse-unless-explicitly-allowed behavior.

[roomote-roomote]

Reviewed. No blocking issues; 1 low-severity optional suggestion below. See task

The fix is coherent: DOCKER_WORKER_ALLOW_UNBOUNDED_DISK=true parses correctly via optInBoolean() (packages/env/src/index.ts:54), production compose/env defaults stay false, and the new guard in validate-deployment-artifacts.mjs genuinely asserts the real assignment — the anchored ^...=true$ regex will not match the #-prefixed comment lines above it.

• Low (optional): deploy/ci/deployment-smoke.sh:119 — the smoke env_file block is strictly alphabetically sorted (APP_ENV … TRPC_URL), but the new DOCKER_WORKER_ALLOW_UNBOUNDED_DISK key was inserted after DOCKER_WORKER_RELEASE_PATH instead of its alphabetical position between DEPLOYMENT_CI_REDIS_PORT and DOCKER_WORKER_IMAGE. Moving the key (with its explanatory comment) preserves the block's ordering convention. Non-blocking.