perf(fallback): connect timeout breve + circuit breaker persistente (fast-fail)

Il gateway irraggiungibile costava ~30s x4 tentativi (fino a ~2 minuti) per ogni
chiamata: ora si distinguono i due casi e le chiamate successive sono immediate.

- due timeout separati: `connectTimeoutMs` (default 2500, connect+headers) e
  `timeoutMs` (default 30000, budget per il body). Nessuna risposta entro il
  primo = "gateway non raggiungibile"; body lento = "elaborazione lunga"
- circuit breaker persistente in ~/.local/share/pi-qmem/breaker.json
  (env QMEM_BREAKER_FILE): fallimento definitivo (connessione rifiutata/DNS/
  connect timeout) → nessun retry e apertura immediata per `breakerBaseMs`
  (default 120000 = 2 min) con escalation fino a `breakerMaxMs` (10 min);
  5xx/body lento sono ambigui → retry con Retry-After e apertura dopo
  `breakerTripAfter` (default 2). Un successo lo richiude; cambiando `url` lo
  stato riparte chiuso (endpoint-aware)
- con breaker aperto gatewayRequest ritorna in ~0 ms senza rete
  (`gateway_unreachable`, `breaker_open`, `retry_in_ms`): i tool passano subito
  al fallback locale e l'outbox accoda
- fix di due bug scoperti durante i test:
  * `res.json().catch(() => ({}))` trasformava un body non completato in
    "successo con dati vuoti" → l'agente vedeva "nessun risultato" invece del
    fallback locale. Ora è `timeout_body` (fallimento, ambiguo)
  * `submitOrQueue` passava un AbortSignal esterno, che con la nuova semantica
    sarebbe stato letto come annullamento utente (eccezione invece di coda)
- messaggi dei tool con lo stato del breaker e come forzare un tentativo;
  `details.breaker` per l'osservabilità
- comandi: `/qmem:local breaker [reset]` e `qmem-sqlite breaker [--reset]`;
  lo stato compare in `/qmem:local status` e nella CLI
- budget interni per enrich/pull/flush (niente AbortSignal esterni)

Misure: connessione rifiutata → 4-8 ms (prima: 4 x 30 s); front che risponde
503 dopo ~40 s → 3,5 s alla prima chiamata, poi 0 ms di rete a breaker aperto;
server che accetta e non risponde → 708 ms (connect timeout); body lento →
1,2 s senza aprire il breaker; persistenza verificata fra processi distinti.

Test: scripts/test-local.mjs 38/38 (nuova fase dedicata al breaker).

skills/qmem/SKILL.md

@@ -39,8 +39,13 @@ In quel caso:
   soglia 0.45/0.60 da applicare;
 - i risultati sono **osservazioni più vecchie** del gateway (storico ricostruito
   dalle sessioni pi + ultimo enrich): verifica prima dell'uso;
-- comandi: `/qmem:local status | import | find <query> | enrich | pull`
-  (`import` dalle sessioni, `enrich`/`pull` dal gateway quando torna online).
+- comandi: `/qmem:local status | import | find <query> | queue | flush | breaker [reset] | enrich | pull`
+  (`import` dalle sessioni, `enrich`/`pull` dal gateway quando torna online);
+- **circuit breaker**: quando il gateway non risponde entro `connectTimeoutMs` (default 2,5 s) le
+  chiamate successive falliscono in ~0 ms **senza toccare la rete** per ~2 minuti (stato in
+  `~/.local/share/pi-qmem/breaker.json`): il fallback locale è immediato. Un 5xx o un body lento
+  sono invece "ambigui" (retry con `Retry-After`, apertura dopo 2 fallimenti). Reset:
+  `/qmem:local breaker reset`.
 
 `qmem_store` accoda in locale: con il gateway giù il record entra nell'**outbox**
 locale (SQLite), è subito ricercabile (marcato ⏳) e viene inviato al gateway al