docs: tab pagamenti e riordino task in produzione

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

STATUS.md

@@ -62,7 +62,32 @@ reale del pannello, nessuna migration (verificato: `tasks.status` è `text` senz
   lavoro vero non era il nuovo stato ma i tre letterali ricopiati a mano in otto file:
   ora tutto deriva da `TASK_STATUSES` in `src/lib/task-status.ts`.
 
-⚠️ **Deployate e servite, non ancora provate a mano.** Build e lint verdi, immagine
+**In produzione dal 2026-08-20**, secondo giro (`b49d4bf`, `1fa8e1a`, migration `0019`):
+
+- **Tab pagamenti.** Mettere una rata su "saldato" la faceva saltare in fondo: `payments`
+  non aveva **nessuna** colonna d'ordine e nessuna delle 13 query che la leggono aveva un
+  `ORDER BY`, quindi Postgres restituiva l'ordine fisico e una `UPDATE` in MVCC riscrive la
+  tupla in coda. In produzione **3 progetti su 5 erano già scombinati**. Per questo il
+  backfill della `0019` **non** ordina per `ctid` (avrebbe fotografato lo scombinamento) ma
+  per `percent DESC` con tie su `label`. Ora le rate si rinominano, gli importi si
+  sovrascrivono a mano (`amount_locked` li esclude dal ricalcolo) e lo scarto fra somma
+  rate e totale viene **dichiarato**, non aggiustato di nascosto. Schema a 3 rate: 50/25/25.
+- **Riordino dei task** dentro la fase, trascinando. `PhasesTab` è un Server Component con
+  closure `"use server"` inline, quindi non è stato convertito: le righe restano
+  server-renderizzate e `SortableTaskList` ci monta attorno solo la maniglia.
+
+Due bug chiusi per strada, entrambi vivi in produzione: `rescalePayments` azzerava le righe
+con `percent` NULL appena una riga del progetto ne aveva uno (ed è proprio quello che
+produce `splitPayment`), e il selettore di schema cancellava `status`/`paid_at` senza
+chiedere, con due rate già saldate a rischio.
+
+⚠️ **Provato a runtime, non ancora cliccato.** Build di produzione contro il DB vero via
+tunnel SSH, in sola lettura: pagina progetto 200, 27 maniglie di trascinamento (esattamente
+i task delle fasi con più di un task), rate nell'ordine giusto. Restano da esercitare a mano
+le tre scritture nuove — `reorderTasks`, `updatePaymentField`, `clearPaymentOverride` — e il
+drag vero e proprio.
+
+⚠️ **Il giro precedente resta deployato ma non provato a mano.** Build e lint verdi, immagine
 `9a57e45` viva, `/admin/login` risponde 200. Restano da esercitare in UI le due
 interazioni: la matita di rinomina con il dialog di conferma, e il drag di un task in
 "In revisione" con il controllo che la fase risulti *attiva*. Non sono state automatizzate