fix(pg-connection-string): keep %XX escapes with hex letters when re-encoding

[breken-ai]

If a connection string has a space or a stray % anywhere in it, parse() runs it through encodeURI() and then tries to undo the double encoding of escapes that were already there. The undo regex is /%25(\d\d)/g, so it only handles escapes made of two decimal digits. %40 comes through fine, but %2F, %3A, %2B, %3f and any other escape with a hex letter stay double encoded and come back literally.

This hits people who follow the usual advice to percent-encode special characters in the password and also put a readable options value in the URL:

parse('postgres://app:s3cr%2Ft@db/prod?options=-c search_path=app').password
// before: 's3cr%2Ft'
// after:  's3cr/t'

Take away the space (options=-c%20search_path%3Dapp) and the same password parses correctly, so the result depends on some other part of the URL. Against a local Postgres 14 with a role whose password is s3cr/t:, new Client({ connectionString: 'postgres://app:s3cr%2Ft%3A@127.0.0.1:55437/postgres?options=-c search_path=app' }) fails on master with password authentication failed for user "app" and connects with this change (show search_path returns app). Generated cloud passwords often contain /, + and =, which are the escapes that break.

The fix matches any two hex digits, case-insensitively: /%25([0-9a-f]{2})/gi. An escape that was already valid is still restored exactly once, and an invalid % is still encoded as %25.

Tests: added two cases to packages/pg-connection-string/test/parse.ts, one with a space plus uppercase escapes and one with a stray % plus a lowercase escape. Both fail on master (expected 's3cr%2Ft%3A' to equal 's3cr/t:', expected 's3cr%2bt' to equal 's3cr+t') and pass with the fix. The full package suite passes (82) and the 100% coverage check passes. eslint and prettier are clean on the changed files.

This PR was prepared with an AI coding assistant, and the failing tests, fix and local Postgres check above were all run before opening it.