feat(portale): gli stati dei task si distinguono, e "in revisione" dice di chi e' la palla

Nella Timeline — la vista di default — lo stato di un task era solo un cerchietto
colorato: ambra col puntino da 1.5px per "in corso", violetto col puntino da 2px per
"in revisione". A 20px sono lo stesso oggetto. Solo "in revisione" aveva un title; gli
altri tre stati non avevano ne' testo, ne' tooltip, ne' aria-label — l'opposto della
regola UX 3 del design system, che chiede colore + testo, mai colore da solo.

Il punto pero' non era la somiglianza fra i due colori. "In revisione" non significa
quello che dice 5547e55, che lo descriveva come controllo qualita' interno: nel flusso
reale vuol dire "consegnato, aspetta l'OK del cliente". E' uno stato che richiede
un'azione, e per questo un cerchietto muto era il problema vero.

- Le quattro icone si distinguono per forma, non solo per colore, quindi reggono anche
  in bianco e nero e con un daltonismo: vuoto -> punto -> spunta vuota -> spunta piena.
  La spunta compare a lavoro finito e si riempie a lavoro confermato.
- Pill di testo solo su "in corso" e "in revisione". "Da fare" e' un cerchio vuoto e
  "fatto" ha il titolo barrato: etichettarli aggiungeva rumore, non informazione.
- Il conteggio dei task in attesa sta nell'header della fase, quindi si legge anche a
  card chiusa. Serve davvero: l'admin puo' forzare una fase su "completata" dalla
  select, e in quel caso la card parte collassata con dentro la richiesta.
- Legenda + micro-copy sopra entrambe le viste: chi revisiona, e che ogni pagina include
  un giro di revisione — l'informazione commerciale che il cliente non aveva da nessuna
  parte. Rimanda alla chat della fase, che esiste gia'.
- Colonne del kanban cliente colorate con le stesse tinte dell'icona in Timeline: prima
  erano quattro colonne grigie identiche.
- Icona aria-hidden + sr-only, cosi' lo screen reader annuncia lo stato anche sui due
  che non portano la pill.

La barra di avanzamento non e' stata toccata: un task in revisione conta come uno in
corso, cioe' zero. Cambia il tipo di lavoro, non l'avanzamento — gonfiare la percentuale
le avrebbe fatto dire una cosa che il contatore "x di y task" smentiva una riga sotto.

Visual e copy in un solo file, e la legenda si genera da TASK_STATUSES: un quinto stato
non lascera' indietro una lista scritta a mano. Stessa disciplina di 5547e55, nata
proprio perche' due liste fisse avevano fatto sparire dei task senza un errore.

Nessuna migration: e' solo UI.

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

STATUS.md

@@ -1,6 +1,6 @@
 # ClientHub (IAMCAVALLI) — Status
 
-_Ultimo aggiornamento: 2026-08-21_
+_Ultimo aggiornamento: 2026-08-22_
 
 Questo è **l'unico documento narrativo** del progetto: a che punto siamo, cosa manca,
 cosa abbiamo imparato. `.planning/STATE.md` è il digest che leggono i comandi
@@ -248,6 +248,51 @@ già annotato in `client-chat.ts` come «un lavoro a sé». Ordine giusto: **att
 poi notifiche (Resend c'è già), poi eventualmente menzioni. Molto probabilmente vedere
 *chi* ha scritto risolve gran parte del problema da solo.
 
+### Stati dei task, resi leggibili nel portale (2026-08-22)
+
+Nella Timeline — la vista di default — lo stato di un task era **solo un cerchietto
+colorato**: ambra col puntino da 1.5px per «In corso», violetto col puntino da 2px per
+«In revisione». A 20px sono lo stesso oggetto. Solo «In revisione» aveva un `title`; gli
+altri tre stati non avevano né testo, né tooltip, né `aria-label`. Il design system chiede
+l'opposto, ed è la sua regola UX 3: **colore + testo, mai colore da solo**.
+
+**«In revisione» non significa quello che dice il commit che l'ha introdotto.** `5547e55`
+lo descriveva come controllo qualità interno («finito, ma da controllare prima di
+consegnarlo»). Nel flusso reale è **«consegnato, aspetta l'OK del cliente»**: la palla è al
+cliente. Un cerchietto muto per uno stato che *richiede un'azione* era il problema vero,
+più della somiglianza fra i due colori.
+
+Cosa è cambiato:
+
+- **Le quattro icone si distinguono per forma**, non solo per colore, quindi reggono anche
+  in bianco e nero e con un daltonismo: vuoto → punto → **spunta vuota** → spunta piena. La
+  spunta compare quando il lavoro è finito e si riempie quando è confermato.
+- **Pill di testo solo su «In corso» e «In revisione».** «Da fare» è un cerchio vuoto e
+  «Fatto» ha il titolo barrato: etichettarli aggiungeva rumore senza aggiungere informazione.
+- **Il conteggio dei task in attesa sta nell'header della fase**, accanto a «4 di 8 task»,
+  quindi si legge anche a card chiusa. Serve davvero: l'admin può forzare una fase su
+  «Completata» dalla select, e in quel caso la card parte collassata con dentro la richiesta.
+- **Legenda + micro-copy** sopra entrambe le viste, che dice chi revisiona e che **ogni
+  pagina include un giro di revisione** — l'informazione commerciale che il cliente non
+  aveva da nessuna parte. Rimanda alla chat della fase, che esiste già.
+- **Colonne del Kanban cliente colorate**, con la stessa tinta dell'icona in Timeline:
+  prima erano quattro colonne grigie identiche.
+- **Lo screen reader legge lo stato su tutti e quattro** (icona `aria-hidden` + `sr-only`),
+  non solo sui due che portano la pill.
+
+**La barra di avanzamento non è stata toccata.** Un task in revisione conta come uno in
+corso — cioè zero. Cambia il *tipo* di lavoro, non l'avanzamento: gonfiare la percentuale
+avrebbe fatto dire alla barra una cosa che il contatore «x di y task» smentiva una riga
+sotto.
+
+Visual e copy stanno in un solo file, `src/components/client/TaskStatusIndicator.tsx`, e la
+legenda si genera da `TASK_STATUSES`: aggiungere un quinto stato non lascia indietro una
+lista scritta a mano. È la stessa disciplina di `5547e55`, nata proprio perché due liste
+fisse avevano fatto sparire dei task dal portale **senza un errore**.
+
+⚠️ **Scritto e compilato, non ancora visto a schermo.** Build e typecheck verdi, lint
+invariato (12 errori preesistenti, nessuno nei file toccati). Nessuna migration: è solo UI.
+
 ### v2.5 — Audit (Phases 27–30), in pausa
 
 Il servizio di analisi sito (tre livelli: **Radiografia / Prima-Dopo / Rotta**) diventa