[WAF-59] Add PostgreSQL backup, restore, failover guidance, and recovery drills

Objective

Document and test backups, point-in-time recovery prerequisites, restore verification, migration rollback, connection failover behavior, and operator recovery drills.

Deliverables

• Implement the complete scoped behavior described above.
• Keep request-path work independent from UI, PostgreSQL, and blocking audit I/O.
• Use Zig 0.17-dev and dependencies pinned through Pantry; do not add Git submodules.
• Keep public APIs explicit about ownership, resource limits, errors, security policy, and compatibility.
• Add focused unit, integration, differential, fuzz, benchmark, and documentation coverage as applicable.

Acceptance criteria

• The scoped implementation and tests are merged on main in small conventional commits.
• Zig formatting, focused tests, and the relevant CI suite pass.
• Compatibility claims have executable evidence and no unexplained skips or silent fallbacks.
• Untrusted inputs have deterministic bounds; hot paths have benchmark evidence.
• Documentation and the machine-readable compatibility matrix are updated.

Relationships

• Parent: WAF-00

Blocked by

• WAF-50
• WAF-51

Blocks

• WAF-69
• WAF-72
• WAF-73

Baselines

• ModSecurity 3.0.16
• Coraza 3.7.0
• OWASP CRS 4.28.0
• libinjection 4.0.0
• Zig 0.17-dev resolved and locked through Pantry

Closed by 76e6e2c.

docs/postgres-operations.md covers backup, PITR prerequisites, restore verification, migration rollback, failover behaviour, and operator drills — each verified by running it against the pinned 18.4 server:

• A base backup restored and started, containing exactly the rows present when it was taken and none of those written after: the assumption that fails during an incident.
• PITR to a chosen timestamp, with the server log confirming recovery stopping before commit of transaction 22875 — the excluded write absent, the included one present.
• The fleet integration suite run against the recovered database: all 54 tests passed. This is the drill that catches a restore which succeeded technically but left the schema unusable.
• Migration rollback and connection-loss recovery, both already asserted by the integration suite.

One trap is documented because it was hit: zig build pg-test caches a successful run, so repointing PG_TEST_DSN at a recovered database reports 7/7 steps succeeded with run test cached and never connects. That output looks exactly like a passing drill while certifying an untested backup, so the documented procedure runs the test binary directly and requires the All N tests passed line.