debito 14: il report stampa il TWR (+10,61%), non il bonifico (+243%)

`trades_db.py --report` calcolava e1/e0-1 sulla serie grezza di equity: il 96,3% del
numero era il versamento di $1.399,39 del 25/08. La riparazione (journal.movimenti_capitale)
esisteva e non aveva attraversato il confine fra i due lettori della stessa serie (P1).

- src/live/journal.py: `rendimento_twr` — funzione unica, spezza la serie sui movimenti
  CERTI e moltiplica i segmenti; gli ambigui restano dentro, dichiarati (P12); tre stati.
- scripts/live/trades_db.py: report() la chiama; stampa TWR con segmenti datati, movimenti
  elencati, trading al netto, delta $ etichettato "movimenti INCLUSI"; il % grezzo sparisce.
- test: +5 in test_journal.py (incl. riproduzione del +10,80% del diario 01/09, M23),
  +2 in test_trades_report.py sul testo stampato con connect() deviato in tmp. 832 verdi.
- docs: CLAUDE.md §5.14 chiuso, §2 e §13 aggiornati; memoria 40; diario 02/09.

Limite ereditato e dichiarato (D5): +10% di trading fra due letture consecutive tocca la
soglia del rilevatore e a mercato fermo verrebbe classificato movimento.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RziUCB336YPUUyDJ29x4Ke

docs/memory/40-produzione-e-deploy.md

@@ -692,6 +692,20 @@ e i vincoli di deploy (PRIIPs/UCITS/broker).
   📌 **IL DB** (`data/live/trades.db`, dentro il perimetro del backup): `fills` col contesto del
   segnale a quel giro (tp_frac, skh_sign, entry, target, posizione, equity), `roundtrips`
   **derivati e ricalcolati da zero**, `equity` oraria, `journal`. Sync **orario** in `cron_book`.
+  📌 **IL RENDIMENTO DEL LIBRO E' UN TWR, NON `e1/e0-1`** (debito 14, trovato il 01/09 e chiuso il
+  02/09/2026). `--report` stampava «+243%» su una serie che conteneva **un solo salto**, il
+  versamento di $1.399,39 del 25/08: il 96,3% del numero era un bonifico. La riparazione
+  (`movimenti_capitale`, che classifica ogni salto oltre `EQUITY_JUMP_ALERT` come *movimento* se
+  supera 2× il massimo che il mercato misurato poteva fare a tetto di leva, altrimenti *ambiguo*)
+  viveva gia' nel giornale e **non era arrivata al secondo lettore della stessa serie** — una
+  variante di P1 che non e' un sorvegliante che ridichiara, ma una riparazione che non si propaga.
+  Ora `journal.rendimento_twr` e' la funzione unica: spezza la serie all'equity PRIMA e DOPO ogni
+  movimento certo e moltiplica i segmenti (gli ambigui non spezzano: restano nel rendimento,
+  dichiarati accanto — P12). Il report stampa TWR, segmenti con le date, movimenti elencati,
+  trading al netto, e il delta $ grezzo solo etichettato «movimenti INCLUSI». Verifica M23: la
+  macchina riproduce il +10,80% del diario 01/09 sui suoi quattro punti. **Limite ereditato:** un
+  +10% di trading fra due letture orarie consecutive, a mercato fermo, sarebbe classificato
+  movimento — e' il limite dichiarato del rilevatore live (D5), non uno nuovo.
   **Le tre fonti si INCROCIANO e non si sovrascrivono:** log (ora vera) x jsonl (i fill) x venue
   (autorevole ma **TRONCA** — 1 trade su BTC, 0 su ETH). `reconcile()` riporta le divergenze e
   **non ripara niente da solo**: fra due fonti che non concordano, una riparazione silenziosa e'