fix: a compiled query can be bound to a transaction

[productdevbook]

A hazard the previous two PRs made more likely, found by asking what a compiled query does inside a transaction.

The trap

A compiled query captures the instance it was built from — that is what lets it run itself. A transaction checks out its own connection, so a query compiled outside one sends its statement down the pool:

client (the transaction): ["BEGIN", "ROLLBACK"]
pool   (outside it):      ["INSERT INTO users …"]   ← committed

The write commits while the transaction around it rolls back.

pglite cannot show this. It has one connection, so the write appears to participate and the rollback appears to take it back — the probe against pglite came back clean and the bug was still there. It took a recording pool to see.

This gets more likely the more the compiled path is used, which is exactly what #192 and #193 have been encouraging.

The fix

const addUser = db.insertInto("users").values({ … }).toCompiled<Args>()

await db.transaction(async (tx) => {
  await tx.prepared(addUser).run({ … }) // on the transaction's connection
})

tx.prepared(...) compiles the SQL again for that instance — once, not per call — and leaves the original untouched.

The tests pin the trap as well as the fix. A test that only covered the correct usage would pass just as happily if the trap came back.

pnpm test green: 3315 tests, lint clean, types clean.