feat(harness): riscrittura skill tht-sessione (F1-F8 + 4 sottomoduli)

Skill ex-novo che riflette Thoth (non copia di ChironeWp3):
- vocabolario widget-descriptor (reviewer_select/decide/confirm) invece di 'dialog native'
- D11 save-one in F2 (upsert mirato vs full resync)
- D14a value_grounded (LSH multi-colonna non collassa) + D14b concept_formula in F4
- D13 free-text e D15 rollback nelle discipline trasversali
- memory vive SOLO nel vectordb (drop registry, spec 5): save-one/promote senza registry
- F8 datamart onesto (stub NotImplementedError)

Sottomoduli cte/memoria/rewriting/sql-generation portati adattando nsp->tht, con
i vincoli precisi trasferiti fedelmente (max 5 memorie, solo 3 tipi riusabili,
CTE solo WITH senza SELECT, dim_time join non aritmetica, sql_final pulito).

Verifica: zero residui nsp/chirone/psd nella skill; ogni 'tht <cmd>' citato e'
registrato (correzione: 'tht formula retrieve' era inesistente -> riformulato in
'ricerca nelle evidence'). Suite: 165 passed.

harness/.pi/skills/tht-sessione/memoria.md

@@ -0,0 +1,40 @@
+# Presentazione delle memorie riapplicabili
+
+Le memorie arrivano da `tht memory search "<domanda>" --session <id> --json`,
+gia' ordinate per similarita'. Tu le argomenti, il reviewer decide. MAI
+applicarle da solo. **Passa SEMPRE `--session <id>`**: la CLI esclude le memorie
+gia' decise in questa sessione (applicate o rifiutate), cosi' non riproponi cio'
+che il reviewer ha gia' scartato (anche dopo un reopen della Fase 2).
+
+Per ogni memoria da presentare in checklist, includi nella `label` e/o
+`description` dell'opzione:
+
+- **Cosa dice**: tipo + soggetto + detail (es. "table_promoted:
+  fact_seeablazione — tabella principale per le ablazioni").
+- **Da dove viene**: question_context e session_id di origine.
+- **Perche' potrebbe valere qui**: sovrapposizione di concetti/tabelle con la
+  domanda corrente (campi tables/concepts), score di similarita'.
+- **Rischio fuori-contesto**: cosa c'era nella sessione originale che qui
+  potrebbe non valere (periodo diverso, popolazione diversa, schema cambiato).
+
+Regole:
+
+- Proponi al massimo **5** candidate. Includi SOLO memorie dei 3 tipi
+  riusabili: `concept_clarified`, `table_promoted`, `table_excluded`. Le
+  decisioni query-specifiche (es. `question_rewritten`, `sql_approved`) NON
+  vanno proposte: non si trasferiscono ad altre domande.
+- Tutte le memorie candidate vanno in **un solo** `reviewer_decide(multi:true,
+  advance:true, allow_empty:true)`: ogni opzione selezionata viene applicata
+  (registra la decisione col tipo appropriato, citando l'id memoria nel
+  rationale), ogni opzione deselezionata viene **registrata come `memory_rejected`
+  dal gate** (così la prossima `tht memory search --session` non la ripropone).
+  Per abilitare questo, OGNI opzione memoria DEVE portare il campo
+  `mem_id:"mem-<id>"` (oltre a `type`/`subject`/`rationale`). La checklist parte
+  pre-selezionata con le memorie raccomandate. Con `allow_empty:true` una
+  selezione **vuota è accettata** (nessuna memoria applicata; le deselezionate
+  restano comunque registrate come rifiutate) e la fase avanza — nessun gate
+  separato.
+- Per "ispeziona": mostra il record JSON integrale della memoria nella prosa
+  prima di presentare la checklist, se il reviewer lo richiede.
+- Se nessuna memoria supera score 0.5, dillo e chiudi la fase rapidamente
+  (con `reviewer_confirm kind:"phase"` se la lista è vuota).