Key tested-image cache by sealed release identity

Problem\nThe container job caches release-image.tar under only the source SHA. Schema-2 release identities also include a run-time version and constructed_at. A later manual promotion of the same SHA can restore an image labeled with an earlier identity and fail provenance, even though the image was valid for the original run.\n\nObserved on 2026-08-24 for SHA 522c47d3d001a1ab083919b58c25eb51db301c63: push run 32680937557 passed container verification with version 20260824-014815-522c47d; manual run 32682462766 restored that cache entry but expected 20260824-021544-522c47d and failed before publish/deploy.\n\n## Scope\n- Include the sealed schema-2 identity in the tested-image cache key so a cache hit can only restore an image built with the same release labels.\n- Add or adjust workflow contract tests for the cache key.\n- No Dockerfile, application runtime, deployment, or AWS changes.\n\n## Acceptance\n- A cache hit is valid only for the exact sealed source SHA, version, and constructed_at identity.\n- Existing automatic rerun reuse remains possible for the same sealed identity.\n- Manual reuse_existing_image=false builds a fresh image when its identity differs.\n- Focused CI tests and the normal CI quality gates pass.

Locate the container job's tested-image cache key and the existing workflow contract tests, then inspect how the sealed schema-2 identity is represented. Update the cache-key contract so source SHA, version, and constructed_at all participate, and verify automatic reuse, differing manual identities, and the focused CI quality gates.