Merge testing into master to reset the merge base

[jsokol]

Caution

Merge this with "Create a merge commit". Do NOT squash or rebase.
The entire point is the second parent — squashing produces the same files but leaves the merge base at 81cb9e2, so the next testing → master comparison conflicts exactly as badly as this one did. The repo permits squash merges, hence the warning.

Description

The first-ever testing → master merge. The merge base was still 81cb9e2 (PR #144, July 2026): every shared change in the four months since had landed as a separate cherry-pick on each branch, so git saw both sides as independently modified and the branches could never be diffed or merged cheaply.

After this, the merge base is af02e01 (current testing tip), and future syncs are ordinary small merges.

Nine conflicts, resolved deliberately rather than by picking a side.

Kept master's — testing still carries the pre-cutover release path

File	Why
push-to-dockerhub.yml	Stays deleted. testing's copy still has the push: master trigger that rebuilt from the prod bundle and broke the 20260820-001 GA. The other three push workflows and update_workflows.sh auto-resolved as deletes.
promote-latest.yml	master's build-once GA promote (both images, GHCR mirror, currency guard) over testing's old minimal-only copy.
simplerisk/Dockerfile, simplerisk-minimal/Dockerfile	testing's carry ENV version=20260519-001 — taking them would have reverted the GA version. Regenerated at 20260820-001 rather than hand-merged, since they're generated artifacts.
.grype.yaml	Comment-only difference; master's wording is version-agnostic and stays correct now the minimal default is php 8.5. Ignore lists verified identical.

Took testing's — strict supersets, verified zero master-only lines

File	Why
publish-testing.yml	The live RC publisher with the resolve/publish-full jobs; master's copy was the old dormant one. Re-applied environment: testing from #161, which testing predates — and extended it to publish-full, which uses the same Docker Hub credentials.
entrypoint.sh, README.md	The DB_UPGRADE headless schema-upgrade feature, whose db-upgrade.php auto-merged in.

CLAUDE.md resolved as a union: testing's DB_UPGRADE row, master's promote-model CI/CD bullets and php-default note.

Release Notes

None — internal change. Brings the DB_UPGRADE headless schema-upgrade mode to the master branch's image sources; it was already live on testing.

Manual Validation Steps

1. Confirm nothing publishes on a master push — create_new_tag.yml should be the only push: master trigger, and it only tags.
2. Confirm the five cutover deletions held: push-to-dockerhub.yml, push-to-gh-pkgs.yml, both _rw.yml, update_workflows.sh.
3. grep '^ENV version=' simplerisk/Dockerfile simplerisk-minimal/Dockerfile → both 20260820-001.
4. grep -c 'environment: testing' .github/workflows/publish-testing.yml → 2.
5. After merge: git merge-base origin/master origin/testing → af02e01, not 81cb9e2.
6. Next RC push to testing should behave identically — this PR does not change testing.

Type of Change

• Build / CI configuration
• Repository maintenance (merge-base reset)

Testing Results

• No conflict markers anywhere in the tree.
• Both generator harnesses pass and leave the committed Dockerfiles clean (the generator_checks guard).
• actionlint clean on all five remaining workflows.
• shellcheck -S error (CI's gate) clean on all tracked scripts.
• make update_version VERSION=20260820-001 → exit 0, idempotent.
• Verified container-validation.yml auto-merged correctly: gained testing's branches: [master, testing] while keeping master's generator_checks and php 8.5 jobs.
• Not exercised: publish-testing.yml only runs on a testing push, so its merged form on master is dormant and untested here. It is byte-identical to what is already running on testing apart from the two environment: testing lines, which mirror what ci: declare per-workflow permissions and move registry creds to environments #161 already validated on master's copy.

CIA Impact Check

MAY negatively impact Confidentiality, Integrity and/or Availability.

Justification for the change

• A four-month-old merge base made every cross-branch comparison unreliable and every future sync a large conflict-resolution exercise — the kind that silently reverts things, which is exactly the risk this PR had to navigate.
• master and testing had drifted on real content (DB_UPGRADE, grype scoping, container-validation triggers) with no mechanism forcing reconciliation.

Potential impact on Confidentiality, Integrity and/or Availability

Integrity (the main risk, mitigated). A careless resolution here would have reverted the GA version to 20260519-001, restored the auto-rebuild trigger, or downgraded promote-latest.yml — each silently. Every one of those was checked explicitly and is listed above with its resolution; the verification steps assert them on the merged tree. No release-path behaviour changes: promote-latest.yml is byte-identical to what is on master today.

Availability (low). The image sources on master gain the DB_UPGRADE code path, but it is inert unless DB_UPGRADE is set, and it has been running on testing since before the last RC. container-validation now also triggers on testing-targeted PRs, which only adds coverage.

Confidentiality. Net positive — environment: testing now scopes the Docker Hub credentials on both credential-using jobs in publish-testing.yml, where testing's copy had no environment scoping at all.

Additional Implementation Steps

No schema change, no customer action.

Follow-up worth considering: testing still holds stale copies of promote-latest.yml and the four deleted push workflows. They are inert there (promote-latest is dispatch-only; the push workflows would need a master push, which cannot happen on testing), but a master → testing sync would make the branches genuinely identical and keep the next merge trivial.