feat(auth): gate OTP email sul portale cliente (v2.3 Phases 23-25)

Il portale /client/<slug> era protetto dal solo token in URL: chiunque
ricevesse o intercettasse il link entrava, per sempre, senza identificarsi.
Ora l'admin registra le email autorizzate per cliente e il cliente si
identifica con un codice usa-e-getta prima di vedere qualsiasi dato.

- Resend 6.18.1 + src/lib/mailer.ts (Result tipizzato, mai catch silenzioso)
- migration 0015 (gia applicata a prod): client_emails, otp_codes,
  clients.sessions_valid_from. Additiva pura, conteggi verificati pre/post
- admin: sezione "Accessi al portale" in /admin/clients/[id] con whitelist
  e revoca sessioni in blocco
- gate: codice 6 cifre CSPRNG, hash SHA-256 (mai il codice in chiaro),
  TTL 15 min, max 5 tentativi, rate limit su entrambi gli endpoint,
  risposta identica per email in whitelist e non (no enumeration)
- sessione: cookie HMAC per-cliente, 90 giorni, httpOnly/secure/lax

Il gate sta in cima alla page, NON nel layout: nell'App Router il segmento
page viene renderizzato in parallelo al layout, quindi gattare nel layout
nascondeva la dashboard a schermo ma lasciava fasi, task e pagamenti nel
payload RSC dell'HTML (46907 byte -> 17594 dopo il fix). Verificato.

Verifica: build OK, 9/9 test E2E in locale contro il DB di produzione.

NON DEPLOYARE prima di: RESEND_API_KEY+RESEND_FROM su Coolify e whitelist
popolata per i 3 clienti reali (oggi vuota) - altrimenti il gate li chiude
fuori dal loro portale. Checklist in .planning/STATE.md.

SEND-01/02 (invio preventivo via email) rinviati a v2.4 su richiesta.

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

.planning/REQUIREMENTS.md

@@ -7,22 +7,21 @@
 
 ### Email OTP Gate (AUTH-OTP-01)
 
-Portale cliente blindato da email OTP. Nuovo `client_emails` table (whitelist) + `otp_codes` table (codice, email, expires_at, consumed). Resend come provider email. Sessione 30gg con cookie dopo verifica.
+Portale cliente blindato da email OTP. Nuovo `client_emails` table (whitelist) + `otp_codes` table (codice, email, expires_at, consumed). Resend come provider email. Sessione **90 giorni** con cookie dopo verifica, revocabile dall'admin.
 
-- [ ] **OTP-01**: Admin può aggiungere e rimuovere email dalla whitelist di ogni cliente nell'admin UI
-- [ ] **OTP-02**: Cliente senza sessione OTP vede una schermata "inserisci email" invece della dashboard
-- [ ] **OTP-03**: Sistema invia OTP via Resend solo se l'email inserita è nella whitelist di quel cliente
-- [ ] **OTP-04**: Cliente inserisce il codice OTP ricevuto e ottiene sessione autenticata (cookie 30 giorni)
-- [ ] **OTP-05**: Codici OTP scadono dopo 15 minuti dall'invio
-- [ ] **OTP-06**: Endpoint OTP è rate-limited per prevenire brute force
-- [ ] **OTP-07**: Messaggi di errore OTP non rivelano se l'email è in whitelist o no (no enumeration)
+- [x] **OTP-01**: Admin può aggiungere e rimuovere email dalla whitelist di ogni cliente nell'admin UI
+- [x] **OTP-02**: Cliente senza sessione OTP vede una schermata "inserisci email" invece della dashboard
+- [x] **OTP-03**: Sistema invia OTP via Resend solo se l'email inserita è nella whitelist di quel cliente
+- [x] **OTP-04**: Cliente inserisce il codice OTP ricevuto e ottiene sessione autenticata (cookie **90 giorni**)
+- [x] **OTP-05**: Codici OTP scadono dopo 15 minuti dall'invio
+- [x] **OTP-06**: Endpoint OTP è rate-limited per prevenire brute force
+- [x] **OTP-07**: Messaggi di errore OTP non rivelano se l'email è in whitelist o no (no enumeration)
+- [x] **OTP-08**: Admin può revocare in blocco tutte le sessioni attive di un cliente
 
-### Invio Link Preventivo via Email (PUB-03)
-
-Admin invia link deck pubblico al lead direttamente dall'admin UI. Usa stessa infrastruttura Resend del OTP gate.
-
-- [ ] **SEND-01**: Admin può inviare link `/preventivo/[slug]` via email al lead con un'azione dall'admin UI
-- [ ] **SEND-02**: Email inviata via Resend include link deck + nome cliente, template minimale in italiano
+> **[2026-07-28] Modifiche alla spec del 2026-06-21**, decise in sessione:
+> - Sessione **90 giorni** invece di 30 (rientro più fluido), compensata da OTP-08.
+> - **SEND-01/SEND-02 spostati al backlog v2.4**: il preventivo si invia a mano, l'automazione non serve ora. Phase 23 si è ridotta alla sola infrastruttura Resend, che l'OTP usa comunque.
+> - **Il gate NON sta nel layout** ma in cima a ogni page sotto `/client/[token]/`. Nell'App Router il segmento `page` viene renderizzato in parallelo al layout: gattare nel layout nascondeva la dashboard a schermo ma lasciava fasi, task e pagamenti nel payload RSC dell'HTML (verificato: 46.907 byte con i dati → 17.594 dopo il fix). Helper: `src/lib/client-gate.ts`.
 
 ## v2.4+ Backlog
 
@@ -30,6 +29,7 @@ Admin invia link deck pubblico al lead direttamente dall'admin UI. Usa stessa in
 
 - **PROP-03**: Stripe Payment Link su deck pubblico `/preventivo/[slug]`
 - **PROP-04**: Auto-provisioning cliente/progetto/fasi al "Vinto" nel CRM
+- **SEND-01/SEND-02**: invio del link `/preventivo/[slug]` via email dall'admin UI — *rinviato da v2.3 il 2026-07-28, l'invio si fa a mano. L'infrastruttura Resend (`src/lib/mailer.ts`) è già pronta, manca solo l'azione e il pulsante.*
 
 ### Post-Vendita
 
@@ -48,21 +48,22 @@ Admin invia link deck pubblico al lead direttamente dall'admin UI. Usa stessa in
 
 | Requirement | Phase | Status |
 |-------------|-------|--------|
-| OTP-01 | Phase 24 | Pending |
-| OTP-02 | Phase 25 | Pending |
-| OTP-03 | Phase 25 | Pending |
-| OTP-04 | Phase 25 | Pending |
-| OTP-05 | Phase 25 | Pending |
-| OTP-06 | Phase 25 | Pending |
-| OTP-07 | Phase 25 | Pending |
-| SEND-01 | Phase 23 | Pending |
-| SEND-02 | Phase 23 | Pending |
+| OTP-01 | Phase 24 | ✅ Done (2026-07-28) |
+| OTP-02 | Phase 25 | ✅ Done (2026-07-28) |
+| OTP-03 | Phase 25 | ✅ Done (2026-07-28) |
+| OTP-04 | Phase 25 | ✅ Done (2026-07-28) |
+| OTP-05 | Phase 25 | ✅ Done (2026-07-28) |
+| OTP-06 | Phase 25 | ✅ Done (2026-07-28) |
+| OTP-07 | Phase 25 | ✅ Done (2026-07-28) |
+| OTP-08 | Phase 24 | ✅ Done (2026-07-28) |
+| SEND-01 | — | ⏭️ Rinviato a v2.4 |
+| SEND-02 | — | ⏭️ Rinviato a v2.4 |
 
 **Coverage:**
-- v2.3 requirements: 9 total
-- Mapped to phases: 9
-- Unmapped: 0 ✓
+- v2.3 requirements: 8 in scope (OTP-01…08) + 2 rinviati
+- Implementati: 8/8 ✓ — verificati con 9 test E2E in locale contro il DB di produzione
+- **Non ancora in produzione**: il codice è scritto e testato ma NON pushato. Vedi i blocchi in `STATE.md`.
 
 ---
 *Requirements defined: 2026-06-21*
-*Last updated: 2026-06-21 — traceability filled after roadmap creation*
+*Last updated: 2026-07-28 — sessione 90gg, OTP-08 aggiunto, SEND-01/02 rinviati, OTP-01…08 implementati*