Hold the pinned image against the repository's schema

Schema v4 gave the deployment a silent drift surface: the pinned pair is
self-consistent, migrating to 3 and serving 3, while this repository has
moved to 4. That reads as healthy, which makes it worse than an error —
the failure is the assumption that the deployment records approver
principal type.

Document v4 in storage-operations, state in the deploy runbook that the
pin predates it, and add a test that requires the statement whenever the
release record's schema version differs from this repository's. Verified
to fail when the acknowledgement is removed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HyybaE7DUXrWYrhbnESCTe

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1275879@bnt-lap001
Assistant-Session: eb464208-f821-41b2-bc5a-a6c33d92a8ad

deploy/README.md

@@ -13,6 +13,17 @@ 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.
 
+**The pinned image predates schema v4.** 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 4
+(`entries.principal_type`, 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 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.
+
 Gates 1 and 2 below are the outstanding ones; nothing is deployed today.
 
 Before applying: