revisione 02/09: il rotolante si CONTROLLA ogni ora (non "si ri-ancora"), TWR con limiti dichiarati e tre stati

Quattro segnalazioni della revisione sui commit di oggi, tutte verificate e riparate.

1. book_execute.py (+ CLAUDE.md §5.7, memoria 40): «il disaster-SL rotolante si ri-ancora ogni
   ora» era falso — ensure_disaster_sl lascia il bracket finche' lo stop e' entro il 5% e la
   taglia entro il 10%; il giro orario CONTROLLA, ri-ancora oltre la tolleranza (mark
   +5,263%/-4,762%). Lo stop siede fra -26,3% e -33,3% dal mark corrente.
2. journal.rendimento_twr: limite dichiarato (D5) — l'intervallo che contiene un movimento
   certo esce intero dal rendimento, il suo P&L di mercato va in `certi`; errore massimo meta'
   del movimento per costruzione (25/08: ~$0,5). Non si stima (P12). Segmenti a lunghezza zero
   non prodotti; nessun tempo a mercato -> 0,0 dichiarato numero.
3. base di equity zero: `twr` E `trading` None con motivo (il salto 0->X e' invisibile al
   classificatore, `trading` valeva l'intero conto); il report stampa n/d.
4. test_book_cadenza: la guardia estrae ogni prescrizione «ogni/every N unita'» e pretende 60
   minuti, con controllo positivo (M15); limite P13 dichiarato.

Test +5 (847 verdi). Diari 02/09 e 02/09b con la sezione "Revisione".

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

@@ -703,7 +703,7 @@ e i vincoli di deploy (PRIIPs/UCITS/broker).
   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
+  macchina riproduce il +10,80% del diario 01/09 sui suoi quattro punti. **Due limiti trovati in revisione (02/09):** l'intervallo che contiene un movimento certo esce INTERO dal rendimento (il suo P&L di mercato va in `certi`; errore massimo META' del movimento, per costruzione; il 25/08 ~$0,5) e a base di equity zero `twr` e `trading` sono entrambi None, perche' il salto 0→X del primo versamento e' invisibile al classificatore. I segmenti a lunghezza zero (movimento nel primo intervallo, o due consecutivi) non si stampano. **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
@@ -923,7 +923,7 @@ rotolante è funzione della **cadenza del cron** (1h: BTC 0 / ETH 1 in 7-8 anni
 con 2 in 30 giorni), quindi chi avesse "corretto" il cron verso il docstring avrebbe spostato il libro
 sulla riga peggiore. La riparazione è il docstring stesso — cadenza ORARIA, la ragione (giro
 idempotente: girare più fitto della griglia non costa ordini, e compra latenza ≤1h per gli
-ingressi/uscite software di SKH01 e un ri-ancoraggio orario del rotolante) e il divieto scritto —
+ingressi/uscite software di SKH01 e un **controllo** orario del rotolante — che si ri-ancora solo oltre la tolleranza di `ensure_disaster_sl`, mark +5,263%/−4,762% o taglia >10%: la prima stesura diceva «si ri-ancora ogni ora» ed era sbagliata, corretta in revisione lo stesso giorno) e il divieto scritto —
 più `tests/test_book_cadenza.py`, che **deriva** (P1) le tre dichiarazioni e le confronta: la riga
 citata nel docstring, quella dichiarata nell'intestazione di `cron_book.sh` (`47 * * * *`) e la
 crontab **installata** (`crontab -l`; se non è leggibile il test è SALTATO, non verde — P5). Il