++ fix restore backup

HANDOFF.md

@@ -353,6 +353,31 @@ Scelte non ovvie:
   già vuota. Con il `pull` l'amministratore non vedeva **mai** il riepilogo del
   proprio ripristino.
 
+- **Il tetto degli upload è una variabile sola, `MAX_UPLOAD_MB`.** Prima viveva
+  in tre posti scollegati — `client_max_body_size` in
+  `docker/nginx/default.conf`, `upload_max_filesize`/`post_max_size` in
+  `docker/php/php.ini`, e la regola `max:` nella validazione — e bastava che
+  uno restasse indietro perché il più piccolo vincesse nel modo peggiore.
+  Adesso `entrypoint.sh` genera i primi due (`conf.d/upload-limit.conf` e
+  `conf.d/zz-upload-limit.ini`) e `config/app.php` alimenta la terza.
+
+  **Non rimettere `client_max_body_size` nel blocco `server` di
+  `default.conf`**: una direttiva lì dentro vince su quella generata a livello
+  http e reintroduce in silenzio proprio il disallineamento che questa
+  disposizione esiste per evitare. La validazione tiene un 2% di margine sotto
+  il valore di nginx, così a fermare un pacchetto fuori misura è Laravel, che
+  sa spiegarsi, e non nginx.
+
+  Il sintomo, quando il limite viene superato, non assomiglia affatto a un
+  errore di dimensione: nginx risponde **413 dopo aver accettato zero byte** e
+  chiude. Il browser ha appena iniziato a spedire, la barra si pianta a una
+  percentuale bassa e nessun evento utile arriva all'`XMLHttpRequest` — pagina
+  muta, con l'aria di essersi bloccata. Da qui i tre presidi nella vista:
+  controllo della dimensione *prima* di caricare, `xhr.timeout` con i relativi
+  gestori di `timeout`/`abort`/`error` (senza, un caricamento fermo non produce
+  più nulla per sempre), e il codice HTTP dentro il messaggio, perché 413 e 419
+  non hanno un corpo JSON da cui ricavare una spiegazione.
+
 - **Nell'azzeramento i file si cancellano prima del database.** Svuotare il
   disco è l'unico passo che può fallire per cause esterne (permessi sul
   volume), e fallire lì non ha ancora toccato niente. Nell'ordine inverso un