Promemoria senza ritorni e tre canali per ogni notifica (DD-037, DD-038)

m23: un registro (promemoria_eventi_generati) ricorda i promemoria a 24 e 3 ore
già generati, così eliminare la notifica non li fa rigenerare dal cron né
riaccodare la mail a ogni giro.

m24: la push dei promemoria, che nascono nel database, la manda il worker
mailer/ con lo stesso modulo dell'app (coda notifiche_push_coda, esiti, backoff,
iscrizioni scadute eliminate, push scartate oltre 3 ore). Il sondaggio
pre-partita scrive anche notifiche_utente (tipo sondaggio_cacche): compare
in-app e arriva per email. L'immagine del worker si costruisce dalla radice
del repository per includere src/lib/webpush.server.ts.

Test: 9 di integrazione per m23, 17 per la coda push, 6 per la route del
sondaggio, nuovi casi unitari sul worker; prova end-to-end con un servizio
push finto. Documentazione e catalogo delle notifiche aggiornati.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

docs/DESIGN_DECISIONS.md

@@ -52,6 +52,8 @@ Serve a rispondere a domande del tipo:
 | [DD-034](#dd-034--lallenatore-è-uno-slot-della-squadra-con-tipo-diverso-non-un-giocatore)        | Ruolo allenatore                      |
 | [DD-035](#dd-035--avviso-certificati-calcolato-in-home-visibile-solo-al-titolare-e-agli-admin)   | Avviso certificati in Home            |
 | [DD-036](#dd-036--notifiche-email-via-gmail-da-un-worker-docker-sullhost-di-casa)                | Notifiche email via Gmail             |
+| [DD-037](#dd-037--i-promemoria-evento-ricordano-di-essere-già-stati-generati)                    | Promemoria evento senza ritorni       |
+| [DD-038](#dd-038--ogni-notifica-ha-tre-canali-la-push-dei-promemoria-parte-dal-worker)           | Tre canali per ogni notifica          |
 
 **In valutazione**
 
@@ -1588,3 +1590,125 @@ Se serve un mittente col dominio della squadra, se le mail finiscono in spam anc
 giorno di uso, se si supera il tetto giornaliero di Gmail, o se l'host di casa si rivela poco
 affidabile: passare a un relay con dominio e, in quel caso, valutare Edge Function più `pg_cron`
 al posto del container.
+
+### DD-037 — I promemoria evento ricordano di essere già stati generati
+
+**Data:** 29 settembre 2026  
+**Stato:** Accettata
+
+**Contesto**  
+I promemoria a 24 e a 3 ore (M17, DD-030) evitavano i doppioni con `ON CONFLICT DO NOTHING` sul
+vincolo `UNIQUE (giocatore_id, evento_id, tipo)` di `notifiche_utente`: la riga della notifica
+era l'unica traccia che il promemoria fosse già stato generato. Il giocatore però può eliminarla
+(swipe o ×, DD-030). Senza più la riga, al giro successivo del job (ogni ora per il promemoria a
+24 ore, ogni 15 minuti per quello a 3 ore, finché l'evento non inizia) il promemoria veniva
+rigenerato come non letto. Con il canale email (DD-036) ogni rigenerazione accodava anche una
+mail nuova: un giocatore che eliminava un promemoria ne riceveva una ogni ora fino all'inizio
+dell'evento. Il difetto è stato trovato controllando la logica il 29/09/2026, il giorno in cui il
+worker email è entrato in produzione, e riprodotto sul database locale.
+
+**Decisione**  
+Un registro separato, `promemoria_eventi_generati` (migration `m23_promemoria_gia_generati`), con
+una riga per `(giocatore_id, evento_id, tipo)` scritta dalla funzione `genera_promemoria_eventi()`.
+La notifica in-app si crea solo per le righe **appena registrate**, quindi eliminarla non fa
+ripartire nulla. Il registro è indipendente da `notifiche_utente`, senza policy per i client, e
+sparisce con l'evento o con il giocatore (`ON DELETE CASCADE`). I promemoria già presenti al
+momento della migration sono stati registrati come generati, altrimenti la prima notifica
+eliminata dopo la migration sarebbe tornata come prima. Il vincolo `UNIQUE` di `notifiche_utente`
+resta come seconda difesa. Cron, criteri di selezione, testi e destinatari sono invariati.
+
+**Alternative scartate**
+
+- Non eliminare davvero la notifica (nasconderla con un flag) → scartata: cambia il significato
+  dell'eliminazione per tutte le sorgenti, tocca la RLS e le query del client, e la tabella
+  crescerebbe di righe che il giocatore non vede più.
+- Togliere l'eliminazione dai soli promemoria, lasciando «segna come letta» → scartata: a un
+  giocatore che vuole ripulire l'elenco resterebbero notifiche non eliminabili, incoerenti con
+  le altre.
+- Un flag «già generato» sulla riga dell'evento → scartata: il promemoria è per giocatore, e chi
+  viene aggiunto ai convocati dopo deve comunque riceverlo.
+- Confrontare `creato_il` o lo stato «letta» per capire se ricrearlo → scartata: non distingue
+  una notifica mai generata da una eliminata.
+
+**Conseguenze**
+
+- Eliminare un promemoria lo fa sparire per sempre, e non parte nessuna mail in più. Il numero
+  massimo di mail automatiche per giocatore ed evento resta due (24 e 3 ore).
+- Una tabella in più, che cresce di una riga per giocatore, evento e tipo e si svuota con
+  l'evento.
+- Se un evento viene spostato dopo che il promemoria è partito, non ne parte uno nuovo per la
+  data nuova: è lo stesso comportamento di prima, ora esplicito.
+- `test/integration/promemoria-eventi.test.ts` è la definizione eseguibile: il promemoria
+  eliminato non ricompare, non riaccoda mail, i due tipi sono indipendenti, un convocato aggiunto
+  dopo lo riceve comunque, il registro non è leggibile né scrivibile da un client e sparisce con
+  l'evento. Sul database con la funzione vecchia il test fallisce.
+
+**Riesame**  
+Se gli eventi potessero essere spostati con frequenza e servisse un nuovo promemoria per la data
+nuova, il registro va agganciato anche alla data di inizio, oltre a giocatore, evento e tipo.
+
+### DD-038 — Ogni notifica ha tre canali: la push dei promemoria parte dal worker
+
+**Data:** 29 settembre 2026  
+**Stato:** Accettata
+
+**Contesto**  
+Il requisito è che ogni notifica arrivi su tutti e tre i canali: push, centro notifiche in-app ed
+email. Due casi non lo rispettavano ([catalogo](modules/notifiche.md#catalogo-delle-notifiche)):
+
+- i **promemoria a 24 e 3 ore** nascono dentro il database (job `pg_cron`, M17), che non può
+  firmare né cifrare una push Web (VAPID, RFC 8291): arrivavano solo in-app e per email;
+- il **sondaggio pre-partita** partiva solo come push e non scriveva in `notifiche_utente`, quindi
+  non compariva in-app e, dato che le email nascono da quella tabella (DD-036), non arrivava per
+  email.
+
+Le altre notifiche (messaggio dello staff, turno palloni, sollecito presenze) partono dall'app su
+Vercel e avevano già i tre canali.
+
+**Decisione**
+
+1. **Sondaggio pre-partita:** la route `apri-sondaggio` scrive anche `notifiche_utente` (tipo
+   nuovo `sondaggio_cacche`, un `upsert` per giocatore ed evento come le altre), per i giocatori
+   attivi che non sono allenatori. La mail parte dal trigger di M22 senza altro lavoro. La push
+   resta com'è. Il vincolo `CHECK` sul tipo si estende con la migration `m24`.
+2. **Push dei promemoria:** la manda il **worker `mailer/`**, con un secondo canale accanto alle
+   email. Un trigger accoda ogni promemoria a 24 o 3 ore in `notifiche_push_coda` (stessa
+   struttura di `notifiche_email_coda`); il worker prende il lotto con `FOR UPDATE SKIP LOCKED`,
+   manda la push a tutti i dispositivi iscritti del giocatore e registra l'esito. Usa **lo stesso
+   modulo dell'app** (`src/lib/webpush.server.ts`, senza dipendenze) invece di una copia: il
+   container si costruisce dalla radice del repository. Le iscrizioni che rispondono 404 o 410
+   vengono eliminate, come nelle route. Le push in coda da oltre 3 ore si scartano: un promemoria
+   arrivato a evento iniziato è solo rumore.
+3. La push dei promemoria non dipende dall'interruttore «Email»: dipende solo dai dispositivi
+   iscritti, come le altre push.
+
+**Alternative scartate**
+
+- Far chiamare all'app dal database (`pg_net`, già abilitata) una route che manda la push →
+  scartata: il database dipenderebbe dall'indirizzo pubblico di Vercel e da un segreto condiviso,
+  e `pg_net` è un'estensione del provider (regola 4 di [PORTABILITA.md](PORTABILITA.md)).
+- Vercel Cron → scartato: sul piano gratuito gira una volta al giorno, come già notato in DD-036.
+- Copiare il modulo push nel worker → scartata: due versioni da tenere allineate per codice che
+  cifra e firma.
+- Mandare dal worker la push di tutte le notifiche → scartata: le altre partono già dall'app, si
+  avrebbero push doppie.
+- Un unico stato di coda per email e push → scartata: le due consegne hanno esiti, tentativi e
+  destinatari diversi (una push per dispositivo, un'email per giocatore).
+
+**Conseguenze**
+
+- Il worker non fa più solo email: gestisce due canali (il documento operativo resta
+  [WORKER_EMAIL.md](WORKER_EMAIL.md)). Serve la chiave VAPID privata anche sull'host, un segreto in
+  più. Senza le chiavi il worker parte lo stesso e manda solo le email, segnalandolo nel log.
+- La push dei promemoria dipende dall'host di casa acceso, come le email: se è spento parte alla
+  ripartenza, ma non oltre le 3 ore dalla creazione.
+- Una tabella nuova (`notifiche_push_coda`) e una migration (`m24_push_promemoria_e_sondaggio`).
+- Il sondaggio compare nel centro notifiche e arriva per email ai giocatori attivi, non agli
+  allenatori; la push continua ad andare a tutti i dispositivi iscritti tranne quelli degli
+  allenatori, anche di giocatori non più attivi.
+- Le altre notifiche non cambiano canali e non ricevono push doppie.
+
+**Riesame**  
+Se l'host di casa si rivela poco affidabile per una notifica sensibile al tempo come la push, o se
+il database dovesse comunque chiamare l'app per altro, valutare di nuovo la chiamata dal database
+all'app.