`poolQueryViaFetch` silently drops Pool connection options (statement_timeout, options, application_name, ...)

Summary

When neonConfig.poolQueryViaFetch = true, NeonPool.query() rebuilds a bare connection string from only user, password, host and database before handing the query to neon() over HTTP:

https://github.com/neondatabase/serverless/blob/main/src/pool.ts#L122-L125

const cp = new ConnectionParameters(this.options) as ConnectionParameters;
const connectionString = `postgresql://${euc(cp.user)}:${euc(cp.password)}@${euc(cp.host)}/${eu(cp.database)}`;

Every other connection-level setting the Pool was constructed with is silently discarded on the fetch path. In particular the node-postgres startup parameters that pg normally sends in the StartupMessage are lost:

• statement_timeout
• idle_in_transaction_session_timeout
• lock_timeout
• application_name
• options (e.g. options=endpoint%3D... or -c settings)
• any query-string parameters on the original connectionString

Queries that go through pool.connect() (transactions) keep these settings because they still use the WebSocket Client. So with the flag on, the same Pool behaves differently depending on whether a query is inside a transaction or not.

Why this matters

A common production setup is:

const pool = new Pool({ connectionString, statement_timeout: 300_000 });
pool.on('error', console.error);

statement_timeout here is a safety net so a runaway query cannot hold a connection forever. After enabling poolQueryViaFetch (which is presented as a low-latency drop-in for one-shot queries), every non-transactional query loses that protection with no error, no warning and no mention in CONFIG.md. We only noticed by reading the bundled source.

Expected

Any of these would be fine, roughly in order of preference:

1. Pass the settings through to the HTTP endpoint if the server can accept them (e.g. as part of the connection string / options), so behaviour matches the WebSocket path.
2. If the HTTP path fundamentally cannot honour them, fall back to super.query() (WebSocket) when such options are present, the same way it already does when connect/acquire/release/remove listeners are attached.
3. At minimum, console.warn once when dropping options, and document in CONFIG.md under poolQueryViaFetch exactly which Pool options and connection-string parameters are ignored.

Environment

• @neondatabase/serverless 1.1.0
• Node.js runtime on Vercel (Fluid compute), drizzle-orm neon-serverless driver

Start by inspecting src/pool.ts around lines 122-125 and compare the poolQueryViaFetch path with the WebSocket path used by pool.connect(). Review CONFIG.md for the current option documentation and determine how the listed Pool and connection-string settings should be preserved or handled. Done means non-transactional fetch queries no longer silently lose those settings, or clearly warn, fall back, and document the unsupported behavior.