feat(mcp+runtime): allineamento a Cerbero MCP V2 e flag operativi

Adegua Cerbero Bite alla nuova versione 2.0.0 del server MCP unificato
(testnet/mainnet routing per token, header X-Bot-Tag obbligatorio) e
introduce due interruttori operativi indipendenti per separare la
raccolta dati dall'esecuzione di strategia.

Auth e collegamento MCP
- Token bearer letto dalla nuova variabile CERBERO_BITE_MCP_TOKEN; il
  valore sceglie l'ambiente upstream (testnet vs mainnet) sul server.
  Rimosso il caricamento da file (`secrets/core.token`,
  CERBERO_BITE_CORE_TOKEN_FILE, Docker secret /run/secrets/core_token).
- Aggiunto header X-Bot-Tag (default `BOT__CERBERO_BITE`, override via
  CERBERO_BITE_MCP_BOT_TAG) su ogni call MCP, con validazione lato client
  (non vuoto, ≤ 64 caratteri).
- Cartella `secrets/` rimossa, `.gitignore` ripulito, Dockerfile e
  docker-compose.yml aggiornati con env passthrough e fail-fast quando
  manca il token.

Modalità operativa (RuntimeFlags)
- Nuovo modulo `config/runtime_flags.py` con `RuntimeFlags(
  data_analysis_enabled, strategy_enabled)` e loader che parserizza
  CERBERO_BITE_ENABLE_DATA_ANALYSIS e CERBERO_BITE_ENABLE_STRATEGY
  (true/false/yes/no/on/off/enabled/disabled, case-insensitive).
- L'orchestratore espone i flag, audita e logga la modalità al boot
  (`engine started: env=… data_analysis=… strategy=…`), e in
  `install_scheduler` esclude i job `entry`/`monitor` quando strategy è
  off e il job `market_snapshot` quando data analysis è off. I job di
  infrastruttura (health, backup, manual_actions) restano sempre attivi.
- Default profile = "solo analisi dati" (data_analysis=true,
  strategy=false), pensato per la finestra di soak post-deploy.

GUI saldi
- `gui/live_data.py::_fetch_deribit_currency` riconosce il campo soft
  `error` nel payload V2 (HTTP 200 con `error` valorizzato dal server
  quando l'auth Deribit fallisce) e lo propaga come `BalanceRow.error`,
  evitando di mostrare un fuorviante equity = 0,00.

CLI
- Sostituita l'opzione `--token-file` con `--token` (stringa) sui comandi
  start/dry-run/ping; il default proviene dall'env. Le chiamate al
  builder dell'orchestrator passano anche `bot_tag` e `flags`.

Documentazione
- `docs/04-mcp-integration.md`: descrizione del nuovo flusso di auth V2
  (token = ambiente, X-Bot-Tag nell'audit) e router unificati.
- `docs/06-operational-flow.md`: nuova sezione "Modalità operativa" con
  i tre profili canonici e tabella di gating per ogni job; aggiunto
  `market_snapshot` al cron summary.
- `docs/10-config-spec.md`: nuova sezione "Variabili d'ambiente"
  tabellare con tutti gli env, comprese le bool dei flag operativi.
- `docs/02-architecture.md`: layout del repo aggiornato (`secrets/`
  rimosso, `runtime_flags.py` aggiunto), descrizione di `config/`
  estesa.

Test
- 5 nuovi test su `_fetch_deribit_currency` (soft-error, payload pulito,
  eccezione, error blank, signature parity).
- 7 nuovi test su `load_runtime_flags` (default, override, parsing
  truthy/falsy, blank fallback, valore invalido).
- 4 nuovi test su `HttpToolClient` (X-Bot-Tag default e custom, blank e
  troppo lungo rifiutati).
- 3 nuovi test integration sull'orchestratore (gating dei job in base
  ai flag).
- Test esistenti su token/CLI ping/orchestrator aggiornati al nuovo
  schema. Suite intera: 404 passed, 1 skipped (sqlite3 CLI assente
  sull'host di sviluppo).

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

docs/04-mcp-integration.md

@@ -1,11 +1,15 @@
 # 04 — MCP Integration
 
-Cerbero Bite consuma quattro servizi MCP HTTP della suite (`Cerbero_mcp`):
-`cerbero-deribit`, `cerbero-hyperliquid`, `cerbero-macro`,
-`cerbero-sentiment`. Non utilizza l'SDK Python `mcp`: ogni server
-espone gli endpoint REST `POST <base_url>/tools/<tool_name>` con
-autenticazione Bearer, e Cerbero Bite vi si collega tramite
-`httpx.AsyncClient` long-lived (`clients/_base.py`).
+Cerbero Bite consuma quattro router MCP HTTP della suite Cerbero MCP V2
+(`Cerbero_mcp`): `mcp-deribit`, `mcp-hyperliquid`, `mcp-macro`,
+`mcp-sentiment`. Dalla V2 i quattro router vivono nello stesso processo
+FastAPI dietro lo stesso host (default in-cluster
+`http://cerbero-mcp:9000/mcp-{exchange}`, gateway pubblico
+`https://cerbero-mcp.tielogic.xyz/mcp-{exchange}`). Cerbero Bite non
+utilizza l'SDK Python `mcp`: ogni router espone gli endpoint REST
+`POST <base_url>/tools/<tool_name>` con autenticazione Bearer e header
+`X-Bot-Tag`, e Cerbero Bite vi si collega tramite `httpx.AsyncClient`
+long-lived (`clients/_base.py`).
 
 Telegram e Portfolio, in passato esposti come servizi MCP condivisi,
 sono stati rimossi dal layer MCP e gestiti **in-process** da ogni bot
@@ -22,13 +26,19 @@ con default che corrispondono al DNS della rete Docker
 ecc.). Ogni servizio può essere sovrascritto da una variabile
 d'ambiente dedicata, utile in sviluppo:
 
-| Servizio | Variabile d'ambiente | Default Docker DNS |
+| Servizio | Variabile d'ambiente | Default Docker DNS legacy |
 |---|---|---|
 | Deribit | `CERBERO_BITE_MCP_DERIBIT_URL` | `http://mcp-deribit:9011` |
 | Hyperliquid | `CERBERO_BITE_MCP_HYPERLIQUID_URL` | `http://mcp-hyperliquid:9012` |
 | Macro | `CERBERO_BITE_MCP_MACRO_URL` | `http://mcp-macro:9013` |
 | Sentiment | `CERBERO_BITE_MCP_SENTIMENT_URL` | `http://mcp-sentiment:9014` |
 
+I default mostrati sopra sono il legacy della topologia V1 (un container
+per servizio). Sulla V2 unificata ogni URL deve includere il prefisso di
+router, ad esempio `http://cerbero-mcp:9000/mcp-deribit` o
+`https://cerbero-mcp.tielogic.xyz/mcp-deribit`. Le URL effettive sono
+configurate in `.env`.
+
 Telegram (notify-only) viene configurato direttamente via due
 variabili d'ambiente, lette al boot dal client in-process:
 
@@ -40,17 +50,26 @@ variabili d'ambiente, lette al boot dal client in-process:
 Quando una delle due manca, il client Telegram entra in modalità
 **disabled** e ogni `notify_*` diventa un no-op a livello di DEBUG.
 
-Il bearer token per le chiamate è il token con capability `core` letto
-da `secrets/core.token` (path configurabile via
-`CERBERO_BITE_CORE_TOKEN_FILE`, default `/run/secrets/core_token` nel
-container). Non è loggato.
+Il bearer token per le chiamate è letto dalla variabile d'ambiente
+`CERBERO_BITE_MCP_TOKEN` (vedi `.env`). Sulla V2 il valore del token
+decide quale ambiente upstream serve la richiesta: lo stesso server MCP
+fronteggia testnet e mainnet contemporaneamente, e si passa da uno
+all'altro semplicemente sostituendo il valore della variabile e
+riavviando il bot. Il token non viene mai loggato.
+
+A ogni chiamata Cerbero Bite aggiunge anche l'header `X-Bot-Tag`, con
+valore di default `BOT__CERBERO_BITE` (override via
+`CERBERO_BITE_MCP_BOT_TAG`). Il server MCP scrive il valore nell'audit
+record di ogni operazione di scrittura, così ogni write resta
+attribuibile al bot d'origine.
 
 ```python
 # clients/_base.py — sintesi
 class HttpToolClient:
     service: str            # "deribit", "macro", ...
-    base_url: str           # "http://mcp-deribit:9011"
-    token: str              # bearer
+    base_url: str           # "https://cerbero-mcp.tielogic.xyz/mcp-deribit"
+    token: str              # bearer (testnet o mainnet, scelto da env)
+    bot_tag: str = "BOT__CERBERO_BITE"  # X-Bot-Tag header
     timeout_s: float = 8.0
     retry_max: int = 3      # esponenziale 1s/5s/30s
     client: httpx.AsyncClient | None  # condiviso dal RuntimeContext