Documenta dashboard admin, profili e ambiente locale

Checklist "Fine lavoro" di AGENTS.md per il lavoro dei due commit precedenti.

- DATABASE.md: profili_giocatore creata, user_roles come fonte dei permessi, e
  la nuova sezione Storage per il bucket privato.
- ARCHITECTURE.md: autenticazione e ruoli tra i punti fermi, comandi dello stack
  Supabase locale; gli stessi comandi in CLAUDE.md.
- CHANGELOG.md: la voce è marcata come presente su develop e non ancora in
  produzione.
- PROJECT_STATE.md: i cinque passaggi per attivare login e dashboard in
  produzione, in ordine, con il redirect URI di Google e la query per il primo
  admin. Segnalato che dev e produzione condividono lo stesso database.
- TODO.md: la dashboard esce dal backlog; entra il profilo lato giocatore, senza
  il quale la dashboard resterebbe senza dati.
- modules/profilo-giocatore.md: registrate due scelte fatte in corso d'opera —
  solo Google al posto di "Google oppure Email", e "Visualizza profilo" come
  scheda in linea invece di una schermata separata.

ROADMAP.md resta con la casella non spuntata: la funzionalità è su develop, non
ancora rilasciata.

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

PROJECT_STATE.md

@@ -6,7 +6,9 @@ Ultimo aggiornamento: 30/08/2026
 
 Fase corrente:
 
-Backend migrato al nuovo Supabase proprietario. M1 completata. Profilo Giocatore da implementare (M2).
+Backend migrato al nuovo Supabase proprietario. M1 completata. M2 e M3 scritte e da applicare.
+Autenticazione Google e dashboard amministratore implementate su `develop`, da attivare in
+produzione seguendo i passaggi più sotto. Profilo Giocatore lato giocatore ancora da fare.
 
 ---
 
@@ -56,9 +58,35 @@ Profilo Giocatore (specifica in `docs/modules/profilo-giocatore.md`)
 
 ---
 
+## Autenticazione e dashboard amministratore
+
+Implementate su `develop`, **non ancora attive in produzione**. Il codice è additivo: finché
+i passaggi qui sotto non sono fatti, l'app si comporta esattamente come prima.
+
+Passaggi in ordine, nessuno dei quali è reversibile a metà:
+
+1. **Provider Google in Supabase** — Google Cloud Console: consent screen *External* (scope
+   `email` e `profile`, nessuna verifica richiesta), credenziale *Web application* con
+   redirect URI `https://kfkcldwncxqaixetsjes.supabase.co/auth/v1/callback`. Client ID e
+   secret in *Authentication → Providers → Google*. In *URL Configuration*: Site URL di
+   produzione, più `localhost:8080` e il wildcard delle preview Vercel tra i Redirect URLs.
+2. **Migration M2 e M3** (`supabase db push`). Sono `CREATE` puri: si possono applicare in
+   produzione senza toccare il comportamento attuale.
+3. **Primo admin**, dopo il primo login (l'ID esiste solo da quel momento):
+   `INSERT INTO public.user_roles (user_id, role) SELECT id, 'admin' FROM auth.users WHERE email = '<mail>';`
+4. **Collegamento dei 17 account**: ciascuno accede con Google e sceglie il proprio nome una
+   volta sola. Uno slot già collegato può essere liberato solo da un admin.
+5. **Solo a squadra collegata**: `VITE_AUTH_OBBLIGATORIA=true` su Vercel (fa sparire la
+   selezione libera del giocatore), poi la migration che rimuove le policy `anon` dalle
+   tabelle v1.0. È l'unico passo che cambia il comportamento per tutti.
+
+Attenzione: dev e produzione condividono lo stesso progetto Supabase. Un account di prova che
+collega uno slot lo occupa anche in produzione, e va liberato da un admin.
+
 ## Prossimo sviluppo
 
-**M2** — `profili_giocatore` + Supabase Storage privato + RLS
+Profilo giocatore lato giocatore (caricamento di documento, certificato e foto tessera):
+finché non esiste, la dashboard amministratore mostra profili vuoti.
 
 ---