fix: allow reusing a pool after end

[zfaustk]

Fixes #3635.

Problem

pool.end() currently makes a Pool permanently unusable. It can also resolve before asynchronous client close callbacks finish, and work already queued before end() may be dropped while the pool drains.

That prevents a long-lived global pool reference from being safely drained and reused in serverless lifecycle hooks.

Fix

• wait for every client close callback before resolving pool.end();
• finish requests that were already queued when draining began, while continuing to reject new checkouts during the drain;
• reset the pool lifecycle only after end() has fully resolved, so the same instance can create fresh connections again;
• document the reusable post-end() behavior.

Tests

• focused pg-pool lifecycle tests: 6 passed, covering repeated query → end → query → end, drain-time rejection, delayed client shutdown, queued queries, and multiple idle clients;
• yarn lint;
• Prettier check for all four changed files;
• Node syntax checks and git diff --check.

The complete database-backed yarn test suite was not run locally because this executor has no PostgreSQL service. A standard install also requires local libpq tooling that is unavailable here. The root TypeScript build was attempted after a frozen --ignore-scripts install and stopped in unchanged pg-query-stream code because pg-cursor types were not built in that nonstandard environment. The upstream Node/PostgreSQL matrix remains the full integration gate.

Implementation and test preparation were assisted by Codex. No human-review claim is made.

[zfaustk]

Taking this back to draft for now. I missed a couple of existing tests that still assumed pool.end() made the pool unusable; those tests held checked-out clients and caused the first matrix run to hang. I updated them, and 10 of 11 matrix jobs now pass, but the Node 24 job still exits with code 139 in a pg-native load test. I also want to understand how this fits with the pool work in #3739 before asking for review. I’ll keep digging and mark it ready again only when the matrix is clean and that overlap is clear. Sorry—I put this in the review queue too soon.

[brianc]

k - thanks for the PR tho! I agree reusing a pool might be nice in certain situations - particularly things like "I want to wait for this pool to fully drain, then and only then it can be reused" for serverless style environments. I re-triggered the tests here as the matrix failed AFAICT because of a segfault related to GH infra. LMK when you want a review!