docs: align operations runbooks with manual releases

docs/runbooks/BACKUP-RESTORE.md

@@ -13,7 +13,7 @@ Back up authoritative PostgreSQL data and the minimum manifest required to valid
 
 - Redis/AOF/cache/queue data
 - `.env` or secret files
-- deployment SSH/registry/object-store credentials
+- deployment SSH and object-store credentials
 - backup decryption key
 - TLS private keys or ACME account data
 - raw challenge CSV archives
@@ -53,7 +53,7 @@ The manifest stores no password, connection URL, secret value, license identifie
 
 1. Acquire a backup lock that conflicts with restore and destructive migration but need not block ordinary application reads/writes.
 2. Resolve and verify the exact production host/database identity. Validate free disk for temporary output plus the encrypted artifact.
-3. Confirm PostgreSQL health, client/server major compatibility, active release id, and migration version.
+3. Confirm PostgreSQL health, client/server major compatibility, active three-hash release id, and migration version.
 4. Create a consistent logical dump using PostgreSQL 18 `pg_dump` custom or directory format. Capture stderr and fail on a non-zero exit.
 5. Inspect the archive table of contents with `pg_restore --list`; reject an empty/truncated/unreadable archive.
 6. Build the non-secret manifest and calculate the plaintext archive SHA-256.
@@ -86,7 +86,7 @@ Run monthly and before any approved destructive migration.
 5. Treat the dump as trusted code only if it came from the approved bucket/path and passes provenance checks. PostgreSQL warns that restore executes statements controlled by the dump source.
 6. Create a new empty database from `template0` or the equivalent approved empty-cluster procedure. Do not reuse a partially populated database.
 7. Restore with error-stop semantics and reviewed owner/privilege behavior. Preserve complete stdout/stderr in a restricted evidence path without secrets.
-8. Run the selected release's validation suite:
+8. Check out/build the selected release record if needed, then run its validation suite:
    - expected migration/import manifests
    - representative table/session/attempt counts and invariants
    - at least two merchant logins and cross-tenant denial
@@ -115,10 +115,10 @@ If any input is absent or mismatched, exit before stopping writers, dropping/ren
 
 1. Announce maintenance and stop public writes/new sessions. Preserve an operator-only health path.
 2. Acquire the exclusive deployment/restore lock; stop worker before backend so no jobs write during restore.
-3. Capture the active/previous release manifests, database identity, incident timestamps, and current-state backup when safe.
+3. Capture the active/previous three-hash release records, database identity, incident timestamps, and current-state backup when safe.
 4. Perform all download/decrypt/checksum/archive/provenance checks from the rehearsal procedure before mutating database state.
 5. Restore into a newly created empty database/cluster. Do not pipe an unchecked dump directly into the active production database and do not recursively delete a computed volume/path.
-6. Validate restore completeness and application invariants using the release compatible with the backup manifest. Apply only explicitly approved forward migrations.
+6. Validate restore completeness and application invariants using the three recorded repository commits compatible with the backup manifest. Apply only explicitly approved forward migrations.
 7. Start with empty Redis. Start backend/worker, confirm readiness, idempotent stale-run reconciliation, cold-cache analytics, sessions, and SSE behavior.
 8. Switch application connectivity to the validated restored destination using the approved implementation strategy.
 9. Run public TLS/login/dashboard plus private database/queue/tenant smoke checks. Observe for 15 minutes.