Converge the Dockerfile generators with testing and pin them in CI

[jsokol]

Description

Closes the generator divergence between master and testing. The (version, source_mode) split landed on testing in July (#147) and never came to master, which is why generator_checks was a testing-only job and why master could not produce a context-sourced image carrying a real ENV version.

Commit 1 — converge the generators. Takes testing's four generator files verbatim, so the layer is now byte-identical across branches rather than approximately similar:

IDENTICAL  simplerisk/generate_dockerfile.sh
IDENTICAL  simplerisk-minimal/generate_dockerfile.sh
IDENTICAL  simplerisk/test_generate_dockerfile.sh
IDENTICAL  simplerisk-minimal/test_generate_dockerfile.sh

Commit 2 — container-validation. Adds generator_checks (both harnesses + a guard that fails if either leaves a committed Dockerfile modified), adds the php 8.5 variant, and fixes a name/key skew.

The PHP 8.4 → 8.5 default

Called out because it's the only behavioural change here. The minimal generator's source_mode split and its default bump landed in the same upstream commit, and the minimal harness asserts ARG php_version=8.5 — so the port can't take one without the other.

This corrects stale config rather than changing what customers get: every released image is the testing-built php85 one that GA promotes, so master's committed 8.4 default only ever affected container-validation and a local docker build. Consequences are (a) a local docker build simplerisk-minimal/ now defaults to 8.5, and (b) container-validation gains a php 8.5 job — which is the variant GA actually ships and was previously unvalidated on master.

The job-key skew

Master's matrix was mislabelled in a way that made it misleading to read:

Job key	Built	Label said
simplerisk-minimal-php84	php 8.3	"PHP 8.3"
simplerisk-minimal-php85	php 8.4	"PHP 8.4"

Now php83/php84/php85 each build and are labelled for their own version. (Fixed on testing in ec196ce; this brings the fix across.)

What this deliberately does NOT do

Not a testing → master merge. I trial-merged it: 11 conflicts, three of which silently undo this week's work if resolved carelessly — testing's push-to-dockerhub.yml still carries the push: master trigger that caused the 20260820-001 failure, and its promote-latest.yml is the old minimal-only version with no GHCR mirror. The merge base is still 81cb9e2 (July), because this repo has always landed shared changes as separate cherry-picks on each branch.

Resetting that merge base is still worth doing, but as its own deliberate exercise right after an RC cut when the branches are closest — not as a side effect of closing a four-file gap.

Release Notes

No customer-facing change. Build tooling only. The minimal image's default PHP on a local build moves 8.4 → 8.5, matching the published image.

Manual Validation Steps

1. ./simplerisk/test_generate_dockerfile.sh → 14 checks ok, exit 0.
2. ./simplerisk-minimal/test_generate_dockerfile.sh → 11 checks ok, exit 0.
3. git diff --quiet -- simplerisk/Dockerfile simplerisk-minimal/Dockerfile after running both → clean (this is what generator_checks guards).
4. make update_version VERSION=20260820-001 → exit 0, no churn.
5. ./simplerisk/generate_dockerfile.sh <V> context → no downloader stage, real ENV version=<V>.
6. On this PR, container-validation should now show 6 jobs including php 8.5 and generator_checks.

Type of Change

• Build / CI configuration
• Bug fix (container-validation job-key/label skew)

Testing Results

• Both harnesses pass: 25 checks, 0 failures.
• Committed Dockerfiles regenerated via make update_version; the only substantive diff is the php default — everything else is comment punctuation. Verified line by line.
• The -fsSL guard on the schema fetch survives the regeneration (asserted by the full-stack harness): without --fail, curl writes a 404 body into /simplerisk.sql and the image ships an HTML error page as its schema.
• make update_version VERSION=20260820-001 → exit 0 and idempotent.
• actionlint clean on all remaining workflows. shellcheck -S error (CI's gate) clean on all tracked scripts.
• Not exercised: the actual image builds — that's what this PR's container-validation run does, including the new php 8.5 variant on master for the first time.

CIA Impact Check

MAY negatively impact Confidentiality, Integrity and/or Availability.

Justification for the change

• The generators are load-bearing for the release path (context mode must stamp a real version; download mode must keep the hash-verifying downloader stage) but nothing pinned them on master.
• php 8.5 is the default the released image ships and was unvalidated on master.
• The mislabelled matrix meant a reader checking "is 8.4 covered?" got the wrong answer.

Potential impact on Confidentiality, Integrity and/or Availability

Integrity (net positive). Both generators are now pinned by harnesses in CI, and the guard catches a generator that dirties a committed Dockerfile. The -fsSL schema-fetch guard is now asserted rather than incidental.

Availability (low, local-build only). A local docker build simplerisk-minimal/ with no --build-arg now produces php 8.5 instead of 8.4. Anyone relying on the implicit default gets a different PHP. Published images are unaffected — they are built from testing, which has defaulted to 8.5 since July. Mitigated by the explicit php_version build arg, which is how CI and the release builds already pin it.

Confidentiality. No change. No new secrets, permissions, or network egress; generator_checks runs contents: read with no registry credentials.

Additional Implementation Steps

None. No schema change, no customer action. Anyone with local build scripts that assumed the 8.4 default should pass --build-arg php_version=8.4 explicitly.