docs: verifica del giro 0020, e .env.local non è più utilizzabile

Cosa è stato verificato davvero: build e lint verdi, migration 0020
applicata a prod prima del push con la colonna riletta a conferma,
deploy atterrato (immagine taggata 44be190 = HEAD).

Cosa no, e ora è scritto: le pagine non sono state rese a runtime.
.env.local è scaduto su tre fronti — ADMIN_PASSWORD, NEXTAUTH_SECRET e
la password del DB — e l'host che dichiara (…:5432) è chiuso dal
firewall; il DB vero sta su 127.0.0.1:54321. Estrarre la password viva
dal container è bloccato dal classifier e non è stato aggirato. La nota
tecnica che dava per buone quelle credenziali diceva il falso.

Aggiunto come vedere se un deploy è atterrato: il tag dell'immagine in
docker ps è lo SHA del commit.

REQUIREMENTS: HUB-14 e HUB-15 registrati come fatti, HUB-16 apre la
verifica a mano che resta da fare, e il riallineamento di .env.local
entra fra le cose aperte.

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

STATUS.md

@@ -116,10 +116,19 @@ rinomina riscriverebbe titoli di fasi veri.
 - **"Prezzo finale" → "Investimento finale"** (solo una tantum; il ricorrente resta
   "Canone mensile").
 
-⚠️ **Scritto e buildato, non reso a runtime.** Build verde, migration `0020` applicata e
-verificata in prod, override tutti NULL quindi comportamento invariato finché non si
-tocca. La prova a runtime **non è stata possibile**: la password del DB in `.env.local` è
-ormai stale e l'estrazione di quella viva è stata bloccata. Va guardato in prod.
+✅ **Verificato quel che si poteva verificare.** Build verde, lint senza nuovi warning,
+migration `0020` applicata a prod **prima** del push e colonna riletta dal DB a conferma;
+override tutti NULL, quindi il comportamento resta invariato finché non se ne imposta uno.
+Deploy atterrato: l'immagine in esecuzione è taggata `44be190`, cioè HEAD.
+
+⚠️ **Non reso a runtime, e va detto.** Le pagine non sono state aperte contro i dati veri:
+`.env.local` è scaduto **su tre fronti** — `ADMIN_PASSWORD`, `NEXTAUTH_SECRET` **e la
+password del DB** — e l'host che dichiara (`178.104.27.55:5432`) è chiuso dal firewall.
+Estrarre la password viva dal container è stato **bloccato dal classifier dei permessi**, e
+non è stato aggirato. Quindi: *scritto e buildato*, non *provato*. **Da fare a mano:**
+aprire il portale di un cliente e guardare barra e card offerta, poi `/admin/projects/<id>`
+→ tab Offerte per impostare un override. Perché la verifica locale torni possibile serve
+riallineare `.env.local` alle variabili di Coolify (vedi § Note tecniche).
 
 Cosa manca, e perché:
 
@@ -237,9 +246,16 @@ cui si ricasca.
   `failed`, non fidarsi di valori DKIM annotati in passato: rileggerli da
   `GET /domains` e confrontarli con
   `dig +short TXT resend._domainkey.iamcavalli.net @8.8.8.8`.
-- **`.env.local` non è allineato a produzione.** `ADMIN_PASSWORD` e
-  `NEXTAUTH_SECRET` sono stati ruotati il 2026-07-28 **solo su Coolify**. Per
-  costruire firme o hash validi in prod vanno letti da Coolify, non da `.env.local`.
+- **`.env.local` non è allineato a produzione, e la deriva è peggiorata.** Il 2026-07-28
+  erano stati ruotati **solo su Coolify** `ADMIN_PASSWORD` e `NEXTAUTH_SECRET`; il
+  2026-08-21 si è scoperto stale anche **la password del DB** (Postgres risponde
+  `password authentication failed`) e chiuso dal firewall l'host che il file dichiara,
+  `178.104.27.55:5432` — il DB vero è su `127.0.0.1:54321` dietro tunnel, quindi vanno
+  riscritti host **e** porta. Recuperare la password viva dal container è **bloccato dal
+  classifier**: non si aggira, si chiede all'utente di riallineare il file. Conseguenza
+  operativa: finché resta così, **una modifica al portale si verifica solo guardandola in
+  produzione** — e va detto, invece di far passare "buildato" per "funziona". Le migration
+  non ne soffrono (`docker exec` non usa quelle credenziali).
 - **L'API Coolify rifiuta `is_build_time`** con 422 sul POST a
   `/api/v1/applications/<uuid>/envs`: mandare solo `key`, `value`, `is_preview`.
 - **Una lista di valori validi dimentica in silenzio, una negazione no.**
@@ -273,9 +289,16 @@ cui si ricasca.
 
 ## Note tecniche
 
-- **Il DB di `.env.local` È la produzione** (178.104.27.55). Non esiste un database
-  di sviluppo separato: qualunque cosa si esegua in locale scrive su dati reali.
-  Verificare i conteggi delle tabelle protette prima e dopo ogni prova.
+- **Non esiste un database di sviluppo.** Quello puntato da `.env.local` **è** la
+  produzione: qualunque cosa si esegua in locale scrive su dati reali — verificare i
+  conteggi delle tabelle protette prima e dopo ogni prova. ⚠️ Dal 2026-08-21 quelle
+  credenziali **non autenticano più** e l'host che il file dichiara è chiuso: per
+  raggiungere il DB servono il tunnel su `127.0.0.1:54321` **e** una password viva presa
+  da Coolify. Fino ad allora `docker exec` via SSH è l'unica via.
+- **Controllare che un deploy sia atterrato**: `docker ps` sul server mostra l'immagine, e
+  **il tag È lo SHA del commit** — si confronta con `git rev-parse --short HEAD`. Coolify
+  ci mette ~2 minuti e cambia il suffisso del container a ogni giro: un controllo immediato
+  fa credere a torto che il webhook sia rotto.
 - **Migrazioni**: SQL scritto a mano in `src/db/migrations/` (`drizzle-kit generate`
   è rotto — vanno tenuti in sync `schema.ts` e l'SQL). Si applicano **da locale via
   SSH + docker exec**, senza tunnel — procedura completa in `CLAUDE.md`. Il tunnel