Closes #3008.

Why the pin stays a SHA

SymfonyScaffold fetches Docker infrastructure from dunglas/symfony-docker on the user's machine, at install time, and a Dockerfile plus docker-entrypoint.sh are executable code. Pointing at main would ship whatever upstream HEAD happens to be, unreviewed, into every api-platform new. Two more reasons it has to stay pinned:

• ComposeOverrideWriter patches compose.yaml structurally — it walks services.{php|frankenphp}.environment and throws when it can't find it. An upstream restructure would break scaffolding for everyone at once, with no fix short of an emergency release.
• The CLI ships as a phar, so an older installer would silently pull files it was never tested against.

So: keep the pin, but stop letting it rot.

1. Bump the pin (3c0d177 → 4227566)

Eleven upstream commits. Of the files the scaffold copies, four changed:

Behaviour change worth flagging: since #3000 added .devcontainer to the copy list, this bump also removes init-firewall.sh, AGENTS.md and .claude/settings.json from scaffolded devcontainers — upstream dropped the preinstalled coding agents in favour of an opt-in setup. AgentsScaffold (#2993) already writes AGENTS.md/CLAUDE.md at the project root, so nothing is lost there.

compose.yaml, compose.override.yaml, compose.prod.yaml and .dockerignore are untouched upstream, so the Hydra+Mercure patch still applies cleanly.

2. Keep it fresh automatically

.github/workflows/symfony-docker-bump.yml runs weekly (and on dispatch):

1. compares the pin against upstream main;
2. only proceeds when a file the scaffold actually copies changed — 7 of these 11 commits touch nothing we ship (docs/, README.md, upstream CI), so this is most of the noise gone;
3. repins, runs PHPUnit, scaffolds a --with-docker project, docker compose up --wait, hits /docs.jsonld, and asserts the Hydra + Mercure Link headers;
4. only then opens (or force-updates) the PR, linking that run.

The validation runs before the PR is opened on purpose: a PR pushed with GITHUB_TOKEN triggers no workflows, so this run is the only evidence the bump works. If you'd rather have ci.yml/e2e.yml run on the bot PR itself, swapping in a PAT or App token is the only change needed — there's a comment in the workflow saying so.

On the Link-header assertion

Upstream's Caddyfile uses header ?Link — set only if not already set — and API Platform emits its own Hydra Link on every response it handles. So asserting rel="mercure" on /docs.jsonld fails on a perfectly healthy stack. The check probes a Caddy-served path instead, which is where the injected directive is actually observable. Verified both directions locally:

with the patch:    link: </docs.jsonld>; rel="…#apiDocumentation", </.well-known/mercure>; rel="mercure"
patch removed:     (no link header)

3. Run e2e on pull requests

e2e.yml only ran on push to main, so no PR touching the scaffold — bot or human — ever got Docker coverage. Now it runs on PRs touching bin/, src/, templates/, scripts/, composer.json or the workflow itself, with in-progress runs cancelled.

Supporting change

SymfonyDockerPin (+ scripts/symfony-docker-pin.php) reads/rewrites the pin and filters upstream paths against DOCKER_FILES, so the workflow never restates the pin format or the copy list in YAML where they'd drift from the scaffold. pin refuses a no-op, so a renamed constant can't silently produce an empty PR. DOCKER_FILES is now public — the existing test already reached for it via reflection, which is gone.

Verification

• 118 tests / 233 assertions green; each commit green in isolation. PHPStan clean.
• Detection pipeline dry-run: 15 upstream changed files correctly filtered to the 9 the scaffold copies.
• Scaffolded and booted on 4227566 locally: /docs.jsonld 200, compose patch intact, Link-header probe confirmed discriminating in both directions.