docs: profilo B, collettore research, colonna source, backup giornaliero

Allinea la documentazione alle modifiche di v1.7.0.

- 01-strategy-rules: §3.2 delta short 0.18 (banda 0.12-0.22, OTM>=10%)
  con la motivazione dell'analisi (credit/width ~6% irraggiungibile a
  delta basso); delta_by_dvol aggressiva ritarata; §3.3 width fino a 6%
  (griglia strike 100pt); §3.4 credit/width min 30% -> 8%.
- 05-data-model: option_chain_snapshots alimentata da due collettori
  (live/research) via colonna source; CREATE TABLE + indice aggiornati;
  book_depth_top3 popolato sulle righe research; migrazioni 6 e 7 in
  tabella; backup orario -> giornaliero con nota storica.
- 10-config-spec: valori structure profilo B + nuovo blocco
  research_collector.
- 06-operational-flow: cron summary con i due collettori opzioni.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

docs/05-data-model.md

@@ -229,12 +229,23 @@ NULL = engine attivo.
 
 ### `option_chain_snapshots`
 
-Snapshot della catena opzioni Deribit prelevata in continuo
-(cron `*/15 * * * *`, allineato a `market_snapshots`). Crypto è
-24/7: l'accumulo dataset deve essere continuo, non gateato sulla
-settimana. Ogni tick contiene un quote per strumento entro la
-finestra `[dte_min, dte_max]` di config; tutti i quote prelevati
-nello stesso tick condividono ``timestamp``. Migration `0005`.
+Snapshot della catena opzioni Deribit. La tabella è alimentata da
+**due collettori distinti**, separati dalla colonna `source`:
+
+* `source='live'` — collettore operativo (cron `*/15 * * * *`,
+  allineato a `market_snapshots`). Ogni tick contiene un quote per
+  strumento entro la finestra `[dte_min, dte_max]` di config (1
+  scadenza, ~13-15 strike); `book_depth_top3` NULL.
+* `source='research'` — collettore full-chain (§13-bis, cron orario,
+  opt-in via `research_collector.enabled`). Cattura tutte le scadenze
+  ≤`expiry_max_days` ed entrambe le ali, con `book_depth_top3`
+  popolato. Trasforma il dataset da "skew/premi medi" a backtest
+  opzioni vero (per-trade e standing put).
+
+Crypto è 24/7: l'accumulo dataset deve essere continuo, non gateato
+sulla settimana. Tutti i quote prelevati nello stesso tick
+condividono ``timestamp``. Migration `0005` (tabella), `0007`
+(colonna `source`).
 
 ```sql
 CREATE TABLE option_chain_snapshots (
@@ -255,15 +266,19 @@ CREATE TABLE option_chain_snapshots (
     open_interest    INTEGER,
     volume_24h       INTEGER,
     book_depth_top3  INTEGER,
+    source           TEXT NOT NULL DEFAULT 'live',
     PRIMARY KEY (timestamp, instrument_name)
 ) WITHOUT ROWID;
 ```
 
 Indici: `(asset, timestamp DESC)` per listing recenti, `(asset,
-expiry)` per query per scadenza specifica. ``book_depth_top3`` è
-NULL by design — il collector non chiama l'order book per ogni
-strike per non saturare l'API; lo legge il liquidity gate live solo
-sugli strike candidati al picker.
+expiry)` per query per scadenza specifica, `(asset, source,
+timestamp DESC)` per separare live/research nelle query di backtest.
+``book_depth_top3`` è NULL sulle righe `live` (il collector operativo
+non chiama l'order book per ogni strike, per non saturare l'API; lo
+legge il liquidity gate live solo sugli strike candidati al picker)
+ed è **popolato sulle righe `research`** (1 call orderbook/strumento,
+concorrenza limitata) per modellare lo slippage reale.
 
 **Sblocca**: il backtest non-stilizzato (modulo `core/backtest.py`
 con prezzi reali invece di Black-Scholes), la calibrazione empirica
@@ -363,12 +378,20 @@ idempotente, forward-only:
 | 3 | `0003_market_snapshots.sql` | tabella `market_snapshots` |
 | 4 | `0004_auto_pause.sql` | `system_state.auto_pause_until / _reason` |
 | 5 | `0005_option_chain_snapshots.sql` | tabella `option_chain_snapshots` |
+| 6 | `0006_dvol_history_multi_asset.sql` | `dvol_history` multi-asset |
+| 7 | `0007_option_chain_source.sql` | colonna `source` (live/research) + indice |
 
 ## Backup
 
-Backup orari di `state.sqlite` in
+Backup **giornalieri** di `state.sqlite` in
 `data/backups/state-YYYYMMDD-HH.sqlite`, ritenuti per 30 giorni.
 Operazione idempotente con SQLite `VACUUM INTO`. Lo job è registrato
-nello scheduler dell'orchestrator (`backup_cron = "0 * * * *"`); è
+nello scheduler dell'orchestrator (`backup_cron = "0 0 * * *"`); è
 disponibile anche come CLI `python scripts/backup.py` per backup
 ad-hoc.
+
+> Nota storica: il cron era orario (`0 * * * *`) e accumulava ~16 GB
+> di snapshot full per ~98 MB di dato unico (la stessa catena opzioni
+> ricopiata ~24×/giorno). Portato a giornaliero per ridurre il
+> footprint di ~24× a parità di retention — rilevante prima di
+> accendere il collettore research, che 2-4× la crescita del DB.