sqlitedb: recover a poisoned handle inside a write operation by replaying it

Closes the last deviation recorded for DID-matlab da83fa3. MATLAB
reopens the connection before retrying a READONLY statement, because a
poisoned handle (SQLITE_READONLY_DBMOVED) is cleared by reopening and
never by waiting. mksqlite autocommits, so there the failed statement is
all there is to re-run. In SQLiteDB it is part of a transaction whose
earlier statements die with the handle.

The four write operations (_do_add_branch, _do_add_doc, _do_remove_doc,
_do_delete_branch) now run through a journaling cursor. It records each
statement's SQL, parameters, rowcount, an INSERT's lastrowid and every
row read. On a READONLY at a statement or at COMMIT, _recover_transaction
rolls back the dead transaction, waits on the same backoff schedule,
reopens and replays the journal. Each statement is checked against what
it did the first time before the failed statement runs or the
transaction commits. Only SQL is replayed: files already copied, or
deleted with delete_original, are not needed again. A replay that differs
(another writer took the next doc_idx, a different file is at the path,
a statement fails) is refused, nothing is written, and the original
error is raised.

The tests reproduce a real DBMOVED by replacing the database file under
the open connection. Doing that showed SQLite reports it at the first
write of a transaction rather than at COMMIT, so a COMMIT-only recovery
would have missed the real case. It also showed that a swap after the
first write is not detected at all, which no retry can see.

Adding documents is about 4% slower (1,500 documents: 6.1 s -> 6.4 s).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012Dn4gCNCU2jUGdmfPVCAGK

Author: claude

src/did/did_matlab_python_bridge_implementations.yaml

@@ -153,27 +153,38 @@ classes:
       UserWrite), and a temp-file write probe of the directory -- but print
       the time as ISO-8601 UTC rather than MATLAB's local datestr.
 
-      DEVIATION -- where the retry may run. mksqlite autocommits every
-      statement, so in MATLAB a failed statement is the whole unit of work
-      and re-running it (even after a reopen) is safe. SQLiteDB groups each
-      add/remove/branch operation into one sqlite3 transaction. Rolling back
-      or reopening mid-transaction would silently discard the statements
-      already pending, and a retried tail would then commit a partial
-      operation. So do_run_sql_query retries only when the connection had no
-      uncommitted work before the statement; inside a transaction the error
-      is reported (with diagnostics) and raised at once, and the caller's
-      existing rollback runs.
-
-      DEVIATION -- the commit is retried too. Because Python's writes reach
-      the disk at COMMIT rather than at each statement, that is where a
-      slow-drive failure lands here. Every commit now goes through
-      _commit(), which retries a BUSY / READONLY COMMIT on the same schedule
-      while the transaction is still open. It never reopens -- that would
-      lose the transaction -- so a genuinely poisoned handle (DBMOVED) is not
-      recovered at COMMIT: the error is raised and the operation rolled back.
-      Replaying a whole operation after a reopen would cover that case, but
-      _do_add_doc also copies ingested files, so it is not obviously
-      idempotent; not attempted.
+      DEVIATION -- what is re-run after a reopen. mksqlite autocommits
+      every statement, so in MATLAB a failed statement is the whole unit of
+      work and re-running it after a reopen is safe. SQLiteDB groups each
+      add/remove/branch operation into one sqlite3 transaction, and a
+      poisoned handle takes the transaction's earlier statements with it.
+      Since 2026-10-23 (da83fa3's reopen, carried into the transaction
+      case) the four write operations -- _do_add_branch,
+      _do_add_doc, _do_remove_doc, _do_delete_branch -- run through a
+      journaling cursor (_JournalCursor, @_journaled) that records each
+      statement's SQL, parameters, rowcount, an INSERT's lastrowid and every
+      row the operation read. On a READONLY inside one -- at a statement or
+      at COMMIT -- _recover_transaction rolls the dead transaction back,
+      waits on the same backoff schedule, reopens, replays the journal and
+      checks each statement against what it did the first time, then runs
+      the failed statement (or commits). Only SQL is replayed: files the
+      operation copied, or deleted with delete_original, before the failure
+      are not touched again, which is why the operation is not simply re-run.
+      A replay that differs -- another writer took the next doc_idx, a
+      different file is now at the path, a statement fails -- is refused,
+      nothing is written, and the original error is raised; it is not
+      retried. Two things found while porting: SQLite reports DBMOVED at a
+      transaction's FIRST WRITE, not at COMMIT, so that is where recovery
+      usually happens; and a file swapped out after that first write is not
+      detected at all -- COMMIT "succeeds" into the unlinked file -- which no
+      retry in either language can see.
+      do_run_sql_query, outside a write operation, keeps its own retry: only
+      when no transaction is open, reopening first for READONLY; inside an
+      unjournaled transaction the error is raised at once.
+
+      BUSY at COMMIT is still waited out on the same connection while the
+      transaction stays open, never replayed: a lock clears with time, and
+      the transaction is intact.
 
       DEVIATION -- classification. Like MATLAB, BUSY vs READONLY is judged
       from the error message (sqlite3.Error.sqlite_errorcode would be exact