fix(harness): remediation difetti review — gate↔CLI, D15, D7/D6, D14, robustezza

Implementazione del piano di remediation progressiva sui difetti emersi
dall'analisi dell'harness. Tutto verificato: 214 test Python (incl. L0 su
Postgres reale), 14 test JS del gate, ruff pulito.

Blocco 1 (CRITICA, integrazione gate↔CLI):
- phase advance: gate usa --auto + exit 6; reviewer_confirm kind:phase fa
  advance esplicito che applica i prerequisiti (prima non avanzava per le
  fasi a conferma umana).
- cte plan riceve i --name dal gate (param names); set-question con id
  posizionale; skill `tht search find`; nuovo comando `tht memory save-one`
  con dedup hash client-side in save_one_memory.

Blocco 2 (D15, stato post-rollback):
- campo `phase` su DecisionRecord + effective_decisions phase-aware per i
  subject "a nome" (cte_approved ecc.); _compute_promotions e finalize sulla
  vista effective; finalize confronta col piano CTE effettivo, non glob;
  `decision add --retracts` + comando `decision retract`.

Blocco 3 (D7 read-only + D6 manifest):
- assert_read_only su tutti e quattro i codepath (direct + REST);
- manifest author/summary/updated_at/updated_by/schema_version popolati +
  helper touch_manifest sulle mutazioni.

Blocco 4-5 (D14a/D14b):
- decision_min_phase data-driven via `emits:` in workflow.yaml;
- formula evidence: status auto, search_formulas, gruppo CLI `tht formula`,
  `search find --kind formula`, load_evidence_dir salta i .sql.md.

Blocco 6 (robustezza):
- taskdoc slice promoted_tables + bound enforced; report escaping/bound +
  rsplit note; filtro kind reader REST/direct; conteggio upserted robusto;
  guard REST run_query non-list; LSH disallineato -> LshIndexError.

Blocco 7 (pulizia):
- dead code gate e KIND_TO_TABLE morto rimossi; doc Postgres-only
  (README + connection.py).

Blocco 0 (parziale): test di compatibilità firma gate↔CLI
(tests/integration). Rinviati: fake-Pi runtime completo, artifact-gate da
disco (#23), parità eligibility REST/direct (#28), unificazione
reserved-labels (#30), memory_rejected da deselezione (#33).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

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

@@ -60,7 +60,7 @@ about a domain term, ask the reviewer.
    `schema_linking.json`. Write the artifacts with care; they are the decision surface.
 8. **Candidates are candidates, not truth.** Present LSH/vector/evidence matches with
    their **provenance** (LSH / vector / evidence) and their scores, never as absolute
-   truth. The reviewer may reject them. Verify filter values with `tht search
+   truth. The reviewer may reject them. Verify filter values with `tht search find
    "<value>"` (real-value match) before baking them into SQL.
 9. **Open ambiguities are explicit.** If an ambiguity can't be resolved, offer a
    `reviewer_decide` option "Leave ambiguity open" with a rationale, so the reviewer
@@ -77,8 +77,8 @@ about a domain term, ask the reviewer.
 
 Prerequisite: you must already be in Phase 1.
 
-1. Explore the DWH and knowledge base: `tht search "<term>"` (evidence + schema, LSH
-   over real values) and `tht search --kind evidence "<term>"`. The LSH exposes
+1. Explore the DWH and knowledge base: `tht search find "<term>"` (evidence + schema, LSH
+   over real values) and `tht search find --kind evidence "<term>"`. The LSH exposes
    EVERY column where a value appears — it does not collapse to a single best match,
    so a value like "ablazione" may anchor on multiple columns.
 2. For each ambiguity (clinical term, population, time window, outcome), present a
@@ -154,9 +154,10 @@ Prerequisite: Phase 3 closed.
    with a `value_grounded` option for each candidate column (the LSH exposes all of
    them, not collapsed to the best match). The reviewer chooses the anchor(s).
 4. **Concept formula (D14b).** If a concept (e.g. "fascia pediatrica", "stesso anno")
-   has a candidate SQL formula (found in the evidence or derived from context),
-   present it and let the reviewer approve/reject
-   (`concept_formula_approved`/`concept_formula_rejected`).
+   has a candidate SQL formula, retrieve it with `tht search find --kind formula
+   "<concept>"` (or derive it from the evidence/context), present it, and let the
+   reviewer approve/reject (`concept_formula_approved`/`concept_formula_rejected`).
+   Reflect the approved formula in `schema_linking.json` (`concept_formulas`).
 5. Write `schema_linking.json` (the Phase 4 artifact) and close with
    `reviewer_confirm kind:"phase"`. Do NOT run `tht session check` (that's Phase 5).