Build the full-stack image once at RC time, so GA can promote it

[jsokol]

Description

Prerequisite for the GA promote cutover (FEATURE-ga-promote-cutover → master). That PR makes GA a promote of an existing RC digest rather than a rebuild. For simplerisk/simplerisk-minimal the RC already exists; for the full-stack simplerisk/simplerisk image it does not — that image has only ever been built on master from the prod bundle. This PR gives it an RC build so there is something to promote.

Three changes:

1. simplerisk/generate_dockerfile.sh — decouple version from source-mode.
The generator branched its recipe on the literal string testing, so a context-sourced build could only ever stamp ENV version=testing. That single coupling is what kept the full-stack image out of the build-once model — an RC has to carry a real version to be promotable. Adds the same (version, source_mode) split simplerisk-minimal already has: context COPYs the app from the build context, download emits the hash-verifying downloader stage. Defaults preserve back-compat exactly — a bare testing still selects context, a bare version still selects download.

Also restores --fail on the schema fetch. It is present on master (commit 6351391) but absent on testing; without it curl writes the 404 body into /simplerisk.sql and the image ships an HTML error page as its database schema.

2. publish-testing.yml — build the full-stack RC alongside the minimal one.
New publish-full job tagging <VERSION>-jammy, <VERSION>-noble, bare <VERSION> (= noble, the default) and :testing. amd64-only, matching what the release build published before. No SSM tier — the full-stack image is not part of the managed fleet.

Version resolution is hoisted into a shared resolve job so both publish jobs stamp the same release even if the testing channel rotates mid-run, and each now fetches that exact bundle by name instead of re-listing the channel.

3. container-validation.yml — pin both generators.
The generators are now load-bearing for the release path, but neither harness ran in CI. Adds a generator_checks job running both, plus a guard that fails if a harness leaves a committed Dockerfile modified.

Release Notes

No customer-facing change. Container build/release plumbing only.

Manual Validation Steps

1. ./simplerisk/test_generate_dockerfile.sh → 14 checks, all ok, exit 0.
2. ./simplerisk-minimal/test_generate_dockerfile.sh → still green (unchanged).
3. ./simplerisk/generate_dockerfile.sh 20260519-001 → regenerates the committed Dockerfile with only the intended -fsSL change; no structural drift.
4. ./simplerisk/generate_dockerfile.sh <V> context → no FROM alpine/curl stage, ENV version=<V>, COPY ./simplerisk/ /var/www/simplerisk.
5. ./simplerisk/generate_dockerfile.sh <V> bogus → exits 1 with Invalid source mode.
6. After merge, the next push to testing should publish simplerisk/simplerisk:<VERSION>-jammy, -noble, bare <VERSION> and move :testing.

Type of Change

• Build / CI configuration
• Bug fix (the missing --fail on the schema fetch)

Testing Results

• Both generator harnesses pass locally (14 + existing checks, exit 0).
• shellcheck clean at all severities on both changed/added scripts (CI gates at error). One deliberate SC2016 suppression where $DB_LANG must stay literal — it is a Dockerfile ARG.
• actionlint clean on publish-testing.yml and container-validation.yml.
• YAML parses; job graph is resolve → (publish, publish-full).
• Not exercised end-to-end: the actual RC image build only runs on a push to testing. The first post-merge testing push is the real test.

CIA Impact Check

WILL NOT negatively impact Confidentiality, Integrity or Availability.

The bundle hash verification, the fail-closed download path, and the published tag set for simplerisk-minimal are all unchanged. The full-stack image gains RC tags it did not previously have; no existing tag changes meaning. The --fail restoration is a net integrity improvement — it prevents an image shipping an HTML error page as its schema.