Real SQLite transactions: BEGIN IMMEDIATE and synchronous=FULL (B-88, DAT-74, DAT-52, ARC-07, TX-28, BET-11, DAT-16)

pysqlite's legacy mode emitted BEGIN only at the first DML, so every read
before it ran outside any transaction and a lock wait surfaced as "database is
locked" at an arbitrary later statement; place_bet also mistook that error for
a write-snapshot conflict, which SQLite cannot produce.

- _register_sqlite_pragmas: synchronous=FULL, isolation_level=None and a
  `begin` event that emits BEGIN / BEGIN IMMEDIATE.
- begin_immediate(session): takes the write lock before the first read; called
  first thing in place_bet, request_withdrawal, the scheduler transitions,
  _trigger_payout, the confirmation poller, the reconciler, bump_fee's persist
  phase, deposit crediting / external-spend marking / reinstating, and the
  derivation-index allocation at registration.
- A lock not granted before a broadcast answers service_busy (503, all seven
  languages), nothing built or sent; after a broadcast nothing is undone, the
  rows stay `building` for the reconciler.
- Spec, storico, BUGS.md and CLAUDE.md updated; 37 new tests on a real file DB.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

BUGS.md

@@ -298,17 +298,6 @@ Fix: when a bump would leave change below `DUST_LIMIT_SATS`, the change output i
 dropped and its value goes to the fee (the replacement is then final); `RbfError`
 and every refused bump write a `rbf_bump_failed` audit row.
 
-### B-88 — SQLite transactions are not what the code assumes
-
-pysqlite's legacy mode issues `BEGIN` only at the first DML, so reads before it are
-not isolated, the "write-snapshot conflict" handled in `place_bet` cannot happen, and
-lock waits surface as `database is locked` after 5s in arbitrary places.
-`synchronous=NORMAL` can lose the last commits on power loss (e.g. a registration,
-reusing its derivation index).
-
-Fix: `BEGIN IMMEDIATE` for every money-moving transaction, `synchronous=FULL`,
-explicit handling of busy timeouts after a broadcast.
-
 ### B-89 — Key problems surface only at first use
 
 Startup checks only that the key file exists and `XPRV_ENCRYPTION_KEY` is non-empty;