Sanitize reused PostgreSQL connections at checkout

[Zetazzz]

Default PostgreSQL pool checkouts now run DISCARD ALL, clear node-postgres/Graphile prepared-statement bookkeeping, and destroy clients when reset fails. Promise, callback, and pool.query() checkout paths retain their API behavior. Custom factories keep their own checkout contract.

Rebased onto the current #1744 head (10574e19f6df223edbdfc0f795cdba373c828901), which applies canonical transaction-local request settings after checkout sanitation. #1754 identity/lease remains stacked above this PR.

Performance is measured before making a deployment claim. The committed benchmark and raw JSON cover three alternating rounds of 1,000 operations per arm/workload against PostgreSQL 18.6, Node 24.20.0, localhost TCP, one client, and the application login. On this shared host, prepared SELECT throughput fell about 64%, and complete request-context transaction throughput fell about 7%. The sanitized checkout retained no prepared statement versus one in the baseline. These are local microbenchmarks under unrelated CPU load; repeat against the actual query mix/network before setting a production budget. The README explains why these results do not justify replacing the reset with RESET ALL or introducing an unsafe bypass.

Validation: pg-cache 24 tests and pg-query-context 13 tests passed, including real same-backend reset, prepared SQL reuse, transaction context, and fail-closed replacement. Eleven affected/reset owner builds, frozen install, and supply-chain policy passed. The integration fixture now uses the existing pool owner and guarantees teardown. Full CI passed all 17 jobs on aa8ee794c01da4e3f4cf93d4967ea8ee0f0f4be2.

Refs constructive-io/constructive-planning#1693 (F10).