Reorganize documentation and unify the AI assistant rules

Documentation:
- Add docs/README.md, the documentation index that AGENTS.md pointed to as the
  first file to read but which did not exist.
- One home per piece of information: the feature list stays in ROADMAP.md,
  CHANGELOG.md records only when something shipped, TODO.md only ongoing work.
  Reconcile the entries that had drifted (CSI was both done and pending;
  pagelle, badge social and serie were missing from the roadmap).
- Rewrite DATABASE.md as tables: add giocatori_squadra (already created by a
  migration) and profili_giocatore (planned in DD-016), fix the wrong heading
  levels, drop the duplicated roadmap.
- DESIGN_DECISIONS.md: move the index to the top and sort it, extract the
  template into _template-dd.md.
- ARCHITECTURE.md becomes the technical reference; CLAUDE.md no longer
  duplicates it.
- Add docs/EFFICIENZA_CLOUD.md with the rules previously kept in mem/,
  separating what the code enforces from the goals not yet implemented.
- Fix statements the code contradicted: mutations use setQueryData rather than
  invalidateQueries, and scout_sessioni and giocatori_squadra are not read by
  the code yet.
- Track the v1.0 modules with no spec in docs/modules/ from TODO.md.

AI assistants:
- AGENTS.md is the single source of the rules, now including the technical
  constraints only Claude Code knew about (generated files, Vite plugins, data
  access) and an end-of-work checklist that applies to every assistant.
- CLAUDE.md and .cursor/rules/crapp.mdc point to AGENTS.md instead of
  restating it.
- Remove the five .cursor/*.md files, which Cursor never loaded.

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

mem/features/cloud-efficienza.md

@@ -1,14 +0,0 @@
----
-name: Efficienza Cloud
-description: Regole per minimizzare query, traffico e invocazioni Cloud (piano 20 crediti/mese, 17 utenti)
-type: feature
----
-- Nessun polling (`refetchInterval`) verso il database; sincronizzazione locale via BroadcastChannel/storage dove possibile.
-- QueryClient globale: staleTime 5 min, gcTime 30 min, refetchOnWindowFocus/Mount/Reconnect disattivati, retry 1.
-- Dopo una mutazione aggiornare la cache con `setQueryData`, non `invalidateQueries` (evita riletture).
-- Scout live: scrive solo l'utente che segna; gli altri leggono dati già salvati.
-- Statistiche, badge e classifiche: "write once, read many" — calcolate e salvate una volta a fine partita, mai ricalcolate a ogni apertura pagina.
-- Dati CSI: sincronizzazione periodica server-side salvata su tabella locale; l'app legge solo dal database interno.
-- Push solo per eventi importanti: convocazioni, promemoria allenamento/partita, turno palloni, esito finale.
-- Niente foto/video/chat o funzionalità pesanti.
-- Schema target: team_id, eventi, presenze, azioni_scout, statistiche_aggregate, classifica_csi, notifiche, con indici sui campi di filtro/relazione.

mem/features/portabilita.md

@@ -1,16 +0,0 @@
----
-name: Portabilità su Node.js + PostgreSQL
-description: Vincolo di architettura — l'app deve girare su un normale server Node.js con PostgreSQL, senza servizi esclusivi Lovable Cloud
-type: constraint
----
-L'app deve restare completamente portabile: ogni funzionalità deve poter girare su un normale server Node.js con PostgreSQL.
-
-Regole:
-- Accesso ai dati solo tramite i moduli in `src/lib/*.ts`; i componenti non parlano mai direttamente col database.
-- Vietato usare funzionalità proprietarie Lovable/Supabase non self-hostable (edge functions proprietarie, auth Lovable come unico login, storage proprietario). `src/integrations/lovable/*` resta opzionale e non importato.
-- SQL standard PostgreSQL nelle migrazioni; niente estensioni esclusive del provider.
-- Configurazione solo via variabili d'ambiente standard; niente valori hardcoded.
-- Job pianificati sempre richiamabili con un semplice HTTP POST, così funzionano con qualsiasi scheduler.
-- Web push implementato con Web Crypto (compatibile Node 18+), non con SDK proprietari.
-
-Dettaglio e guida di migrazione: `docs/PORTABILITA.md`.

mem/index.md

@@ -1,2 +1,4 @@
-- [Efficienza Cloud](mem://features/cloud-efficienza) — Regole anti-consumo: niente polling, cache lunga, aggregati precalcolati, sync CSI server-side
-- [Portabilità](mem://features/portabilita) — L'app deve girare su Node.js + PostgreSQL standard, nessun servizio esclusivo Lovable Cloud
+Le regole di progetto non vivono più qui: sono in `docs/`.
+
+- Efficienza cloud → `docs/EFFICIENZA_CLOUD.md`
+- Portabilità → `docs/PORTABILITA.md`