[WAF-50] Implement the Pantry-managed PostgreSQL deployment profile

Objective

Declare PostgreSQL 18 and libpq through Pantry and document service lifecycle, DSN, TLS, credentials, pools, health checks, and production deployment requirements.

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-02

Blocks

• WAF-51
• WAF-52
• WAF-59
• WAF-69
• WAF-71

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

Bootstrap evidence: Pantry resolved PostgreSQL 18.4 and postgresql.org/libpq 18.0.0 after disambiguating the native libpq domain from an unrelated registry package. Service validation found an existing Pantry project already owning port 5432 with a v17 data directory. pantry start postgres created a recoverable v17 backup and reported initdb failure while the existing process remained healthy. No existing process was stopped. WAF-specific cluster isolation/port ownership and upgrade behavior must be implemented and tested here before this profile can close.

Closed by 76e6e2c.

PostgreSQL 18 and libpq 18 are declared in deps.yaml and resolved in pantry.lock, with services.autoStart covering the development lifecycle. docs/postgres-operations.md documents the deployment profile: service lifecycle, DSN (with the two settings that must live in the conninfo string so they survive Conn.reset), sslmode=verify-full and why require is not sufficient, scram-sha-256 credentials and the least privilege the role needs, connection pool budgeting against max_connections, and a health check that verifies the schema version rather than just the connection.