Pulisce a cascata i dati collegati quando un evento viene cancellato (DD-029)

Un audit del modulo Obiettivi ha verificato che gli obiettivi non hanno
bisogno di pulizia: sono ricalcolati a runtime sull'elenco eventi
corrente. Il problema reale era un livello sotto: cancellare un evento
lasciava orfane le righe collegate in 8 tabelle (risposte_presenze,
cacche_partita, mvp_voti, pagelle_voti, badge_social_voti,
turni_palloni, scout_sessioni, scout_live, scout_partite), nessuna con
una foreign key verso eventi_app.

Aggiunge un trigger AFTER DELETE su eventi_app (migration
m14_pulizia_dati_evento_cancellato) invece di una FK con CASCADE, non
applicabile per dati storici disallineati (match_id che a volte punta
a id Scout/CSI). Verificato con un nuovo test di integrazione contro
il database locale; documentato in DESIGN_DECISIONS.md, DATABASE.md,
obiettivi-squadra.md, test/README.md e CHANGELOG.md.

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

docs/CHANGELOG.md

@@ -80,6 +80,10 @@ Prima versione, pre-release.
 - L'MVP di una partita richiede ora un quorum minimo di 2 voti totali (`VOTI_MINIMI_MVP`)
   oltre al margine netto già richiesto: un solo voto non assegna più la vittoria (DD-028).
   Alcuni conteggi `mvp` già mostrati possono scendere per effetto della nuova regola.
+- Cancellare un evento pulisce ora a cascata, tramite trigger database, tutte le tabelle
+  collegate (presenze, pagelle, MVP, badge social, turni palloni, scout) invece di lasciarle
+  come righe orfane (migration `m14_pulizia_dati_evento_cancellato`, DD-029). Le righe orfane
+  generate da cancellazioni precedenti a questa migration non vengono bonificate.
 
 ### Sicurezza