Publish and pin the verified schema-v5 approval candidate

Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a07ff8-19d0-7820-b4d0-1353833cb7fc

deploy/README.md

@@ -5,24 +5,20 @@ deployment. SQLite is intentionally limited to one replica, `ReadWriteOnce`
 storage, and an `OnDelete` update: never start two writers against a copied
 database.
 
-**Image: pinned, published, not rolled out.** Both `image:` references already
-carry the immutable release digest
-`sha256:73333f5ceb55e48192e3095cb2e2a741cdc6ff0be2f18128301072b4a6b6eb9d`
-(registry tag `0.1.0`, OCI index; linux/amd64 manifest `sha256:2064d537…`),
-pinned at `b51d174`. There is no placeholder left to replace. Both references
-MUST stay identical and MUST stay digests — a tag here would let the init
-container and the server run different code against one database.
+**Image: pinned, published, not rolled out.** Both `image:` references carry
+`sha256:251941a5cb2724b57cc32cff6b693b1ab0be695bee4f56f02d51961189c0fa49`
+(registry tag `0.1.0-hfact-be1a388`, source `be1a388`). Both references MUST stay
+identical immutable digests: migration and server share one database.
 
-**The pinned image predates schema v5.** The published artifact recorded in
-[`docs/image-scan-2026-09-06.md`](../docs/image-scan-2026-09-06.md) carries
-`LATEST_SCHEMA_VERSION = 3`; this repository is now at 5
-(`entries.principal_type` plus `approvals.human_control`, see [storage-operations.md](../docs/storage-operations.md)).
-The pinned pair is self-consistent — that image migrates to 3 and serves 3 — so
-nothing is broken by leaving it pinned, but a rollout that must enforce declared human controls or carry approver
-principal-type evidence requires cutting a new image at step 3 below. The
-`migrate` init container then performs the additive upgrade on the existing
-volume; `tests/test_deploy_manifest.py` holds this acknowledgement so the drift
-cannot go quiet.
+The new artifact carries `LATEST_SCHEMA_VERSION = 5`, matching this source:
+`entries.principal_type` and explicit `approvals.human_control`. Its release scan
+found zero HIGH/CRITICAL vulnerabilities. Disposable on-disk v4-to-v5 migration,
+negative service/agent binding, human binding/consumption and restart persistence
+passed inside the non-root container with no network and a read-only root.
+See [the image evidence](../docs/evidence/2026-09-10-human-control-image.json).
+This is artifact evidence; native identity, audit delivery and production restore
+remain deployment gates. Never roll the old v3 image over a v5 database; use the
+matching verified pre-migration backup for rollback.
 
 Gates 1 and 2 below are the outstanding ones; nothing is deployed today.
 

deploy/approval-engine.yaml

@@ -42,7 +42,7 @@ spec:
         seccompProfile: {type: RuntimeDefault}
       initContainers:
         - name: migrate
-          image: forgejo.coulomb.social/coulomb/approval-engine@sha256:73333f5ceb55e48192e3095cb2e2a741cdc6ff0be2f18128301072b4a6b6eb9d
+          image: forgejo.coulomb.social/coulomb/approval-engine@sha256:251941a5cb2724b57cc32cff6b693b1ab0be695bee4f56f02d51961189c0fa49
           args: ["migrate", "--db", "/data/approvals.sqlite"]
           securityContext:
             allowPrivilegeEscalation: false
@@ -53,7 +53,7 @@ spec:
             - {name: tmp, mountPath: /tmp}
       containers:
         - name: approval-engine
-          image: forgejo.coulomb.social/coulomb/approval-engine@sha256:73333f5ceb55e48192e3095cb2e2a741cdc6ff0be2f18128301072b4a6b6eb9d
+          image: forgejo.coulomb.social/coulomb/approval-engine@sha256:251941a5cb2724b57cc32cff6b693b1ab0be695bee4f56f02d51961189c0fa49
           args:
             - serve
             - --production