Sanitize reused PostgreSQL connections at checkout

[Zetazzz]

Summary

• sanitize every checkout from the default node-postgres pool with DISCARD ALL
• clear node-postgres and Graphile prepared-statement bookkeeping after the server discards prepared state
• destroy the client and preserve the checkout error when sanitation cannot complete
• retain Promise, callback, and pool.query() checkout behavior while leaving alternate registered pool factories unchanged

This implements F10 from constructive-io/constructive-planning#1693. It is stacked directly on #1744 because F02 establishes the complete transaction-local request context after F10 restores the reused connection to PostgreSQL defaults.

Scope

The change is owned by pg-cache and applies automatically to its default real PostgreSQL pool. It does not add pool identity, runtime/control credential separation, custom-driver sanitation, checkout telemetry, or other functionality from the original research PR.

The Graphile prepared-statement cache is deleted without invoking its disposer because DISCARD ALL has already removed server-side statements; running asynchronous DEALLOCATE callbacks afterward could race the next checkout.

Validation

• pnpm --filter pg-cache test --runInBand — 24 tests passed
• pnpm --filter pg-query-context test --runInBand — 13 tests passed against real PostgreSQL
• pnpm --filter pg-cache build
• pnpm --filter pg-query-context build
• targeted ESLint on all changed TypeScript files
• pnpm install --frozen-lockfile
• git diff --check

The integration coverage proves same-backend session reset, named prepared-statement reuse with changed SQL, F02 context application after sanitation, direct pool.query() sanitation, and fail-closed replacement of a connection left in an open transaction.

pnpm policy:check is currently blocked by pre-existing expired repository exceptions for @typescript-eslint/eslint-plugin, @typescript-eslint/parser, and @types/semver; this PR does not alter those policies.