fix(client-engine-runtime): refuse statements on a transaction once it starts closing - #30649

Fixes #29762

Problem

When a transaction times out while a query is still running, the query keeps sending its remaining statements on the transaction it was given. Adapters that close a transaction by sending ROLLBACK and then releasing the connection (usePhantomQuery: false, such as @prisma/adapter-pg) run those statements after the ROLLBACK, outside any transaction, so each one commits on its own. The caller gets P2028 and reasonably assumes nothing was written.

A nested write is enough to hit it, because it runs as several statements:

await prisma.$transaction(
  [
    prisma.user.create({ data: { name: 'created' } }),
    prisma.user.update({
      where: { id },
      data: { name: 'updated', posts: { createMany: { data: [{ title: 'first' }, { title: 'second' }] } } },
    }),
  ],
  { timeout: 1000 },
)
// Rejects with P2028. If the UPDATE was blocked past the timeout, the created user rolls back
// but both posts are still created.

Fix

TransactionManager.getTransaction now returns a view of the transaction whose queryRaw and executeRaw throw once the transaction has started closing. The manager sends its own COMMIT and ROLLBACK on the underlying transaction, so closing is unchanged.

A refused statement throws the error a new query on that transaction already gets: TransactionExecutionTimeoutError after a timeout, TransactionClosedError or TransactionRolledBackError otherwise. Callers see no new error. Statements sent before closing began still run inside the transaction and roll back with it.

The guard lives in the transaction manager because it is the only place that knows when closing begins. For usePhantomQuery: false adapters it sends ROLLBACK through executeRaw and calls rollback() only afterwards, to release the connection. A guard set in rollback() comes too late: a statement queued behind the ROLLBACK still runs. With #29769 applied on its own, the regression test below still fails the same way.

Tests

• transaction-manager.test.ts: a statement sent while the timeout ROLLBACK is in flight is refused and never reaches the driver. Statements on a committed or rolled-back transaction are refused. Both tests fail without the fix.
• issues/29762-timed-out-transaction-nested-write (PostgreSQL, run with js_pg): another transaction holds a FOR NO KEY UPDATE lock, so the nested write's UPDATE outlives a 1s timeout. The test asserts the batch rejects with P2028 and nothing was written. Without the fix, both posts commit.