Fix pool recycling after close failures

[leonardovida]

Summary

• preserve pool capacity accounting when closing an expired connection fails
• retry queued acquires instead of leaving them pending after a recycle failure
• add regression coverage for queued and idle recycling paths
• bump the package version to 1.5.4-3

Verification

• pre-commit run --all-files
• bun x prettier --check .
• bun x tsc --noEmit --project tsconfig.check.json
• CI=1 bun test (638 passed, 8 skipped)
• bun run build
• npm pack --dry-run --json
• bun run bench
• live MotherDuck integration tests and NYC example
• failure PoC confirms queued acquire resolves with a replacement
• real DuckDB pool recycle smoke query returned 42

Compatibility

No breaking changes are expected.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 6ce1656255

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Retain connections whose close attempt fails

When closeClientConnection() rejects before closing the resource, as the new tests simulate, this finally block decrements capacity and deletes the only tracked reference while the caller has already removed the connection from idle or leased. The pool then creates a replacement, but pool.close() cannot retry the failed connection, so repeated recycle failures can leak an unbounded number of live DuckDB connections and native resources. Track failed-close connections for later cleanup instead of permanently forgetting them.

Useful? React with 👍 / 👎.