Prevent reserves from stranding after server-side termination

[realies]

A queued reserve() can wait forever when the server terminates a connection. The close handler removes the waiter from the pool queue and passes it into reconnect. Connection startup discards that reserve marker, expecting the pool queue to still contain the waiter, so nothing resolves it.

Keep reserve waiters in the pool queue whenever a connection attempt starts, including reconnects. The normal open handler can then hand out the connection. Also clear the closed session's query, results, and pending error: otherwise a fatal error from an interrupted query can reject a new reserve, and the pool hands the reconnected slot to that already-rejected waiter. A waiter rejected by a failed connection attempt removes itself from the queue, so the pool neither keeps reconnecting for it nor hands a later connection to it.

Adds two tests using the existing t() harness and a real server: terminate a reserved backend while another reserve is queued, and terminate a reserved backend while a query is sleeping before reserving again. Both fail before the patch and pass afterward.

Validation:

• PostgreSQL 16: npm test passes, 266 tests each for ESM, CommonJS, and Deno.
• PostgreSQL 18: all 266 ESM and 266 CommonJS tests pass; both new Deno regressions pass. The full Deno suite does not complete on PostgreSQL 18 for a reason unrelated to this change; it stops the same way without it.
• ESLint passes.

Fixes #1195