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>

docs/ARCHITECTURE.md

@@ -44,7 +44,12 @@ docs/           documentazione ufficiale
   server functions, `attachSupabaseAuth`).
 - **Supabase**: `src/integrations/supabase/client.ts` (browser/SSR, chiave publishable — file
   generato) e `client.server.ts` (`supabaseAdmin`, solo server). `types.ts` è generato dallo
-  schema.
+  schema; finché non viene rigenerato, le tabelle introdotte da M1/M2 si usano tramite
+  `client-nuove-tabelle.ts`, con i tipi di riga dichiarati nei moduli di `src/lib/`.
+- **Autenticazione**: login Google via Supabase Auth (`src/lib/auth.ts`, DD-011); i permessi
+  di amministrazione arrivano da `user_roles` (`src/lib/ruoli.ts`). La variabile
+  `VITE_AUTH_OBBLIGATORIA` decide se `/benvenuto` accetta ancora la selezione libera del
+  giocatore: finché è spenta, login e vecchio accesso convivono.
 
 ## Livello dati
 
@@ -95,6 +100,19 @@ npm run test:e2e          # percorsi sull'app servita
 npm run test:all          # tutto
 ```
 
+Database di sviluppo in locale (Docker), alternativo al progetto Supabase cloud:
+
+```bash
+npx supabase start   # avvia lo stack locale e applica tutte le migration
+npx supabase stop    # spegne i container
+npx supabase db reset # ricrea il database da zero: migration + supabase/seed.sql
+npx supabase db push  # applica le migration al progetto cloud
+```
+
+`supabase/seed.sql` popola qualche profilo di prova e gira **solo in locale**. Serve perché
+il progetto cloud è uno solo, condiviso tra sviluppo e produzione: lo stack locale è il posto
+dove provare le migration distruttive senza toccare i dati veri.
+
 ## Branch e flusso di sviluppo
 
 - `main` → produzione, deploy automatico su Vercel.