docs: record staging restore drill

docs/verification.md

@@ -282,6 +282,16 @@ replace that project without separate operator approval; current source was
 instead rebuilt and exercised in the isolated Compose profiles and the
 project-owned kind cluster.
 
+A mode-`0600` custom-format backup of that exact database was then created at
+`output/backups/compose-20260719-060810.dump` with SHA-256
+`726cca11f69b1aab5e7141ba5f13ebe92c7f27c6b14172891cd2e462acc069f0`.
+Its checksum and `pg_restore` catalog were validated. The restore drill read 23
+public tables and 1,484 rows from a uniquely named temporary database, observed
+PostGIS 3.6.4, applied all 10 current migrations there, passed migration
+readiness, and removed that database. A final read-only source check still
+reported 8 migrations and the same user/request/message counts; the four
+running application container IDs were unchanged.
+
 After the Activity rollout, headed Chrome rendered the updated public
 navigation, followed the Activity link to the authenticated route, and received
 the expected login redirect and flash with zero console errors or warnings.
@@ -430,8 +440,9 @@ The complete local regression was repeated against application commit
   retained bucket was removed, and only the final canonical bucket remains.
 - The ordinary public-facing Compose project was checked read-only: local
   live/readiness, four-node PubSub, public HTTPS home/Safety/readiness, DNS, and
-  TLS passed. Its existing rows and migration level were recorded without
-  changing them.
+  TLS passed. Its current database was backed up and restore-tested through all
+  10 source migrations in a temporary database; its own existing rows,
+  migration level, and running application containers remained unchanged.
 
 ## Known work before a public production launch