feat(live): cap/asset dinamico = equity/2 — operazionalizza la decisione frontier (inerte a $600)

Il cap notional per-asset non e' piu' fisso a $300: con max_notional_per_asset_frac
in config diventa equity/2, cosi' cresce col capitale e un deposito futuro non resta
strozzato (frontiera 2026-07-03). Guardrail: dinamico SOLO con equity reale fidata;
su fallback/offline si torna al cap fisso (protezione downside quando E e' ignota).
Live dry-run: cap $299 a equity $598 -> inerte oggi. Suite 172 passed (+4 test).

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

docs/diary/2026-07-03-cap-dynamic.md

@@ -0,0 +1,47 @@
+# 2026-07-03 — Cap notional per-asset DINAMICO (= equity/2): operazionalizza la decisione frontier
+
+**Contesto.** La frontiera del 2026-07-03 (`docs/diary/2026-07-03-book-frontier.md`) aveva identificato
+**una sola** azione config con impatto reale: portare `max_notional_per_asset_usd` da $300 fisso a
+**equity/2**, perché il cap fisso strozza il book man mano che si deposita (paradosso: più capitale =
+book più freddo — a $5k il cap $300 fa girare il libro al ~49% del target). Il diario la lasciava
+"da applicare AL deposito". Qui la **operazionalizzo in codice** rendendo il cap dinamico, così è
+sempre corretta e non richiede un edit manuale al deposito.
+
+## Cosa è cambiato
+
+- **`src/live/book.py` — `_cap()`**: se in config c'è `max_notional_per_asset_frac` (opt-in), il cap
+  per-asset diventa **`equity × frac`** (0.5 → equity/2). Senza la chiave → comportamento vecchio
+  (cap fisso `max_notional_per_asset_usd`). Il call site in `book_report()` passa
+  `equity`, `real_equity`, `eq_fallback` a `_cap()`.
+- **`config/live.json`**: aggiunto `max_notional_per_asset_frac: 0.5` (+ nota). `max_notional_per_asset_usd`
+  resta come **cap fisso di fallback**.
+- **`tests/test_book_live.py`**: +4 test (scaling con equity fidata, fallback su eq_fallback/real=None/
+  equity 0, no-frac, integrazione online). Suite: **172 passed**.
+
+## Il guardrail di sicurezza (il punto delicato)
+
+Il cap dinamico si usa **SOLO con equity reale fidata** (letta dal conto). Se l'equity reale non è
+leggibile — `eq_fallback` attivo, `real_equity=None`, offline, o equity ≤ 0 — si **torna al cap fisso
+$300**. Motivo: in fallback `equity` è il paper-cap ($2000 ipotetico); calcolare `equity/2 = $1000` su
+un conto di importo reale **ignoto** sizerebbe troppo. Preserva esattamente la protezione downside che
+il test `test_book_execute_eq_fallback_warns_but_proceeds` verificava (l'hard-cap $/asset protegge
+quando E è ignota). Regola: **equity/2 solo quando ci fidiamo di E; altrimenti $300 fisso.**
+
+## Verifica
+
+- **Live dry-run reale** (nessun `--execute`, nessun ordine): `cap/asset **$299**` = $598.06/2 →
+  **INERTE** oggi (≡ vecchio $300). Book flat, HOLD.
+- Offline / `equity_override`: cap resta **$300 fisso** (nessuna equity reale da fidarsi) → il test
+  di parità pre-esistente regge invariato.
+- A $5.000 di equity il cap diventerebbe automaticamente **$2.500** (equity/2), rimuovendo il
+  throttling che la frontiera aveva quantificato.
+
+## Impatto e limiti
+
+- **Già attivo**: il cron orario (`cron_book.sh`) esegue dal working tree → il prossimo run legge già
+  `frac=0.5`. Nessun deploy separato. **Inerte a $600**, si "accende" da sé quando l'equity cresce.
+- **NON avvicina €50/g**: la frontiera lo aveva già detto — è una miglioria marginale (+€0.2/g @2k,
+  +€0.5/g @5k), il cui unico scopo è non lasciare capitale futuro strozzato. €50/g resta un problema
+  di **capitale + tempo** (~130k @ CAGR onesto), non di questo cap.
+- Nessun cambio di **leva** (TP01 `target_vol=20%` invariato, la vol nativa ~10% emerge da sola —
+  coerente col verdetto frontier "gira alla vol nativa, non levare").