fix(sqlite3): run BEGIN, COMMIT and ROLLBACK through exec so a failed COMMIT releases its lock

[just-some-random-pal]

Fixes #361.

On a local file database, a COMMIT that fails with SQLITE_BUSY leaves the database write-locked until the process exits. Every later write from any connection fails with SQLITE_BUSY, even after the failed transaction is rolled back and the reader that caused the busy error is gone. Through @prisma/adapter-libsql this shows up as every later query timing out.

The cause is the one the issue pins down in the libsql binding: transaction control went through db.prepare(sql).run(), and when a prepared COMMIT throws, the statement is left un-reset. An un-reset statement keeps the connection's lock past a successful ROLLBACK and past close(), until garbage collection finalizes it. db.exec() finalizes its statement before returning, whether it succeeded or failed.

This adds executeControl, which runs a statement through exec() and maps the error like executeStmt, and uses it for every BEGIN, COMMIT and ROLLBACK: in Sqlite3Transaction.commit(), rollback() and close(), in Sqlite3Client.transaction(), batch() and migrate(), and in the pool's rollback when a connection is released mid-transaction. 0.18.0's pool already rolls back and drops a connection whose rollback fails, so with the lock no longer stuck, that recovery now works. migrate() also returns its connection to the pool in every case; before, a throwing ROLLBACK in its finally skipped the release.

The libsql 0.6 incompatibility mentioned in the issue is separate and not touched here.

Tests: three cases next to the existing busy-timeout test, one each for a failed COMMIT in transaction().commit(), batch() and migrate(). Each holds a SHARED lock from a read transaction on a second client, lets the COMMIT fail with SQLITE_BUSY, releases the reader, and then writes from the same client and from a new one. All three fail on main with SQLITE_BUSY: database is locked and pass with this change. The local test suite passes (200 passed, 11 network tests skipped without a server), and tsc --noEmit and prettier --check are clean.