Run onexecute regardless of max_pipeline so begin() works at 0

[reinierlakhan]

Fixes #1210

Cause

execute(q) in src/connection.js returns one && chain that does two unrelated jobs: it decides whether the pool may pipeline another query onto this connection, and it runs the query's onexecute hook as its last term:

      return write(toBuffer(q))
        && !q.describeFirst
        && !q.cursorFn
        && sent.length < max_pipeline
        && (!q.options.onexecute || q.options.onexecute(connection))

begin() sends BEGIN with { onexecute } and relies on that hook to capture the connection, move(c, reserved) and set c.reserved. With max_pipeline: 0 the sent.length < max_pipeline term is always false, so the chain short-circuits before the hook. The connection is never reserved, and the UNSAFE_TRANSACTION guard in CommandComplete rejects every transaction.

Change

Run the hook whenever the query was actually written, independent of pipeline capacity, and keep the return value's meaning ("may the pool pipeline more onto this connection") unchanged:

      const written = write(toBuffer(q))
      written && q.options.onexecute && q.options.onexecute(connection)
      return written
        && !q.describeFirst
        && !q.cursorFn
        && sent.length < max_pipeline

max_pipeline > 0: behaviour is identical. onexecute in begin() (the only caller) returns a truthy value (the assigned c.reserved function), so the old chain was truthy exactly when the new one is, and the hook ran in exactly the cases it runs now (previously it also only ran when write() returned truthy, which written && preserves).

max_pipeline: 0: execute() reserves the connection and returns false, so go() moves it to full. c.reserved is set, so the BEGIN passes the guard. On the BEGIN's ReadyForQuery (status T), connection.reserved() runs, finds the transaction's queue empty and moves the connection back to reserved. The transaction callback only starts after that (it is awaited behind the BEGIN), and each statement it issues goes through begin()'s handler: execute() returns false -> move(c, full); anything issued while in full is pushed onto the transaction's own queries and drained one at a time by c.reserved() on each ReadyForQuery. Ordering is preserved and nothing is pipelined onto the socket, which is the point of the setting.

Tests

Three tests added to tests/index.js, each on a client with { max: 4, max_pipeline: 0 }:

• a single-statement sql.begin(sql => sql\select 1 as x`)returns1`
• two sequential statements in one transaction (set_config(..., true) then current_setting, so it also proves they ran on the same transaction)
• two concurrent statements in one transaction (array form), which exercises the queries queue path

Run in isolation against a plain PostgreSQL 16 through the repo's tests/test.js harness: all three pass with this change; without it the first fails with UNSAFE_TRANSACTION. eslint src tests with the repo config is clean.

The full suite did not run here: tests/bootstrap.js needs psql/createdb/dropdb on PATH and a server it may reconfigure (ssl=on, wal_level=logical, prepared transactions), which this environment does not have. CI should cover it.

I left cjs/, deno/ and cf/ untouched, following the pattern of separate build commits in this repo; happy to regenerate them in this PR if preferred.