fix(persistence): finish connection cleanup before a cancellation propagates

[guamiao]

Closes #1780

Problem

Cancelling a transaction while SQLite is executing a statement could leave its pool slot checked
out. With a one-slot pool, the next ping() timed out and the runtime stopped accepting work.
This is the failure behind the Python 3.14 e2e job on #1734, which passed on a re-run and was
therefore merged without a fix.

Two driver-level gaps combine:

1. A statement cancelled mid-await leaves its native cursor held by the exception stack, so the
   rollback that follows fails with Connection closed and the connection never returns to the
   pool.
2. aiosqlite 0.22.1's stop() is not idempotent. SQLAlchemy can drive both a graceful close and
   a stop on the same connection, and the second request is enqueued behind a worker that has
   already exited, so its completion future never resolves.

The defect is pre-existing: it reproduces on the revision before #1734, and on plain SQLAlchemy
without these wrappers.

Change

Driver-level, per connection (sqlite/profile.py)

• Track the cursor handed out by the connection so a cancelled statement can be finalised before
  the connection is retired.
• Make stop() idempotent for the connection: the original stop runs once, its completion future
  is cached, and every waiter gets its own shield so one cancelled waiter cannot poison the
  others. Patched per connection instance; the shared aiosqlite class is untouched.
• Interrupt the statement SQLite is still running when the surrounding await is cancelled.

Transaction exit (database.py)

• A failed transaction now finishes its whole exit — rollback, close, shared-lock release and the
  active-transaction count — inside a managed task, so a repeated cancellation cannot strand the
  cleanup. The original cancellation is then re-raised.
• Only the transaction that owns the connection runs that cleanup, so a nested exit cannot close
  its caller's cursors.
• A clean exit stays in the caller's task, which the seekdb shutdown ordering depends on
  (test_profile_finishes_shutdown_before_propagating_repeated_cancellation).

Verification

Reproduce and fix, on the same host:

	Result
test_repeated_transaction_cancellation_does_not_exhaust_the_pool[sql] without the cursor step	fails — the slot is still checked out after the tenth round (OperationalError: interrupted)
same test with the fix	passes

Full runs:

Environment	Result
Windows, pytest --doctest-modules --ignore=tests/e2e	42 failed / 3013 passed — the failures are the pre-existing set on master, no new ones
Linux 3.14.4, focused (sqlite + seekdb + recorder + e2e)	60 passed
Linux 3.12.3, focused	60 passed
Linux 3.14.4, full tests/e2e	316 passed, 64 skipped
Real embedded seekdb frozen with SIGSTOP	checkout and write paths both bounded; shutdown returns in 0.00s
ruff check / format, ty check	clean

Windows is Python 3.14.4; the CI job pins 3.14.7, which was not obtainable offline.

[guamiao]

CI is green on the first attempt (23/23). Worth noting: re-running the same
suite with the cursor finalisation disabled makes
test_repeated_transaction_cancellation_does_not_exhaust_the_pool[sql] fail,
so the regression test has real discriminating power — this isn't a
re-run-masked pass like the one on #1734.

[Teingi]

Found one transaction atomicity issue in the cancellation path.

[Teingi]

[P2] Prevent partial commits after an interrupted write

SQLite can roll back the entire native transaction when a write is interrupted. Forcing is_disconnect = False lets SQLAlchemy keep using that transaction: insert row 3, catch TimeoutError around a long UPDATE, then insert row 4. The context exits successfully, but row 3 is lost and only row 4 is committed. The base revision raises PendingRollbackError instead. Please mark the transaction invalid or rollback-only so later work cannot commit after earlier writes have been silently rolled back.

[guamiao]

Thanks — you're right, and the reproduction is exact.

Confirmed before fixing: insert row 3, interrupt a long UPDATE, insert row 4, then exit the
context. Before the change the context returned cleanly and only row 4 was committed; the
unmodified baseline raises PendingRollbackError and commits nothing.

The cause is that sqlite3_interrupt() rolls the whole native transaction back when an
INSERT/UPDATE/DELETE is interrupted, while is_disconnect = False told SQLAlchemy the connection
was still trustworthy. That flag was there for a reason — dropping the connection destroys an
in-memory StaticPool database (verified: the next statement fails with no such table) — so the
fix keeps the connection and makes the transaction itself uncommittable instead: the interruption
is recorded on the connection, and the transaction raises PendingRollbackError when it exits
rather than committing its remains.

test_interrupted_write_cannot_commit_earlier_work covers a file-backed and an in-memory
database. Disabling the guard makes both fail.

[Teingi]

The earlier partial-commit issue is fixed. Two regressions remain in cancellation cleanup and connection reuse.

[Teingi]

[P2] Always finish cleanup after the connection is invalidated

With AsyncDatabase.attach(create_async_engine("sqlite+aiosqlite://...")), cancelling an executing statement invalidates the connection through SQLAlchemy's normal cancellation path. This connection.info access then raises PendingRollbackError before _finish_transaction() runs. A real SQLite probe now receives that error instead of CancelledError, leaves one active transaction, and cannot complete database.close() while the operation task remains referenced. The previous commit propagates cancellation and finishes cleanup. Please ensure invalidated or closed connections still reach transaction cleanup and preserve the original cancellation.

[Teingi]

[P2] Clear interruption state after COMMIT finishes

The interruption marker is checked before this call performs COMMIT. If cancellation arrives while COMMIT is blocked, the error handler sets the marker afterward and it remains on the pooled connection. With SQLite DELETE journaling and a reader holding a shared lock, cancelling that COMMIT makes the next unrelated INSERT transaction raise PendingRollbackError and roll back. The same probe succeeds on the previous commit. Please scope or clear the marker when its transaction actually finishes, including cancellation during COMMIT or ROLLBACK, so it cannot affect the next borrower.

[guamiao]

Both regressions are fixed, and each now has a test that fails without its fix.

Invalidated connections reached the wrong place. connection.info re-resolves the DBAPI
connection, so once a cancelled statement invalidated it, reading the mark inside the failure path
raised PendingRollbackError and skipped _finish_transaction() — leaving the transaction counted
as active. The transaction now holds the info dict itself, which stays usable once the connection
is gone, so cleanup runs and the caller still sees the original CancelledError.
test_invalidated_connection_still_reaches_transaction_cleanup and
test_invalidated_connection_preserves_the_original_cancellation cover it; both fail before the
change.

The mark outlived its transaction. The check ran before COMMIT, so a commit cancelled while in
flight recorded the mark afterwards and left it on the pooled connection. It is cleared in a
finally around the exit now, which covers cancellation during COMMIT or ROLLBACK.
test_marker_recorded_during_commit_does_not_survive_the_transaction plants the mark from the
commit event — after the check, exactly where your probe found it — and fails without the cleanup.

One note: an earlier run of tests (3.14) failed on
test_cancelling_a_request_during_a_stalled_usage_write_leaves_the_runtime_healthy[storage-failure]
with "cancelled request did not finish". Re-running it went green, and it does not reproduce locally
(10 focused runs, 3 whole-file, 2 full e2e). That test overlaps a 5s busy_timeout with a 5s wait,
so I read it as a timing-sensitive test rather than a code defect — flagging it rather than quietly
re-running until green.

[guamiao]

Two things from the latest CI, separated because they are different problems.

quality failed on 8998b919: I annotated a commit-event callback object and then
read .info off it. Fixed in 545ab669.

tests (3.14) is the one I want your read on.

test_cancelling_a_request_during_a_stalled_usage_write_leaves_the_runtime_healthy[storage-failure]
failed on de8086f5 and again on 8998b919 with "cancelled request did not finish" — the request
task had not completed 5s after pending.cancel(). Both runs show the same tmp_path and the same
task id, so on CI this is deterministic, not a one-off.

I cannot reproduce it locally, and I have ruled out what I can reach from here:

attempt	result
3.14.4, focused ×20	pass
3.14.4, whole file ×3, full e2e ×2	pass
3.14.5rc1 — closest available to CI's 3.14.7 — focused ×5, file ×3	pass
pinned to 1 and to 2 CPUs	pass

What I did find is that the test's own deadline sits right on top of the configured budget:

busy_timeout_ms=5_000                              # app config
done, _ = await asyncio.wait({pending}, timeout=5) # test

Both are 5s. At the point the request is cancelled, the usage write is stalled on release, so the
transaction still holds SQLite's write lock and record_fails has not made a difference yet. If the
request ends up waiting on that lock, it finishes right at the test's deadline, and which side wins
comes down to scheduling.

Two things I would rather ask than guess:

1. Is a 5s window meant to be sufficient here? If a cancelled request can legitimately take up to
busy_timeout to unwind, the test should either wait longer or wait for an explicit completion
signal instead of a fixed deadline.
2. [storage-failure] is a parametrisation I added earlier in this PR. It runs second, and both
failures are on it — could the second run be starting from a different state than the first?

I would rather not loosen a timeout to make the check green; that is how the failure on #1734 got
masked in the first place. If you read this as a real defect rather than a timing-sensitive test,
say so and I will keep digging — I just cannot get 3.14.7 locally to reproduce it.