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>

docs/scommesse-e-prelievi.md

@@ -108,10 +108,7 @@ ancora `open` oltre la scadenza.
   `service_busy` (HTTP 503), perché il round non è necessariamente in
   chiusura.
   *Codice:* `app/bets/service.py:place_bet` ·
-  *Test:* `tests/unit/test_bets.py`
-  *Stato:* da implementare (B-88) · *Oggi:* la transazione si apre con la
-  prima scrittura, non con `BEGIN IMMEDIATE`; un `OperationalError` viene
-  trattato come un conflitto di scrittura e risponde `round_closing`.
+  *Test:* `tests/unit/test_bets.py` · `tests/unit/test_sqlite_transactions.py`
 - **[BET-22]** `MAX_PARTICIPANTS_PER_ROUND` è minore di
   `MAX_PAYOUT_TX_INPUTS`. Il pagamento spende una moneta del montepremi per
   ogni scommessa, e una singola transazione di pagamento può spenderne al