Dashboard amministratore e profilo per il tesseramento

Implementa la voce "Dashboard amministratore" della roadmap v1.1, come descritta
in docs/modules/profilo-giocatore.md, insieme alla parte di profilo che la
alimenta.

- /admin: stato dei profili della squadra, download di documento, certificato e
  foto tessera, export CSV con i 12 campi del tesseramento CSI. Un certificato
  scaduto non conta come valido.
- Profilo giocatore: dati personali, documento (fronte e retro), certificato e
  foto tessera, con widget di completamento in Home che sparisce al 100%.
- I permessi di amministrazione arrivano da user_roles (DD-011) e non più dalla
  lista di nomi in crapp-data.ts, che resta come ponte finché
  VITE_AUTH_OBBLIGATORIA non viene acceso in produzione.
- Login Google via Supabase Auth: al primo accesso l'account si collega a uno
  slot libero di giocatori_squadra, e il vincolo lo fa rispettare il trigger di
  M1 (DD-016 regola 2).

Migration additive: M2 crea profili_giocatore, M3 il bucket privato
profili-giocatore. Nessuna tabella v1.0 viene toccata, quindi si possono
applicare senza cambiare il comportamento attuale dell'app.

supabase/config.toml e seed.sql configurano lo stack locale: serve perché il
progetto Supabase è uno solo, condiviso tra sviluppo e produzione.

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

supabase/seed.sql

@@ -0,0 +1,37 @@
+-- Seed di sviluppo: gira solo in locale (`supabase start` e `supabase db reset`),
+-- mai in produzione. Serve a vedere la dashboard amministratore con dati realistici
+-- senza inserire righe finte nel database vero.
+--
+-- I path dei file puntano a oggetti che nel bucket non esistono: i pulsanti di download
+-- falliscono finché non carichi qualcosa dall'app o dallo Studio (http://127.0.0.1:54323).
+
+INSERT INTO public.profili_giocatore
+  (giocatore_id, data_nascita, luogo_nascita, indirizzo, telefono, email,
+   documento_tipo, documento_numero, documento_rilasciato_da,
+   documento_emissione, documento_scadenza, documento_fronte_path, documento_retro_path,
+   certificato_scadenza, certificato_path, foto_path)
+VALUES
+  -- Profilo completo al 100%.
+  ('g1', '1997-08-30', 'Bologna', 'Via Roma 1', '3330000001', 'g1@example.test',
+   'Carta d''identità', 'CA1000001', 'Comune di Bologna',
+   '2021-03-01', '2031-03-01', 'g1/documento-fronte.jpg', 'g1/documento-retro.jpg',
+   '2027-06-30', 'g1/certificato.pdf', 'g1/foto.jpg'),
+
+  -- Certificato scaduto: in dashboard deve comparire rosso.
+  ('g4', '1995-05-01', 'Bologna', 'Via Verdi 2', '3330000004', 'g4@example.test',
+   'Carta d''identità', 'CA1000004', 'Comune di Bologna',
+   '2019-05-01', '2029-05-01', 'g4/documento-fronte.jpg', 'g4/documento-retro.jpg',
+   '2025-01-01', 'g4/certificato.pdf', 'g4/foto.jpg'),
+
+  -- Profilo a metà: dati personali sì, documento no, certificato sì, foto no.
+  ('g2', '1996-12-07', 'Modena', 'Via Bianchi 3', '3330000002', 'g2@example.test',
+   NULL, NULL, NULL, NULL, NULL, NULL, NULL,
+   '2027-09-15', 'g2/certificato.pdf', NULL)
+ON CONFLICT (giocatore_id) DO NOTHING;
+
+-- Il primo amministratore non si può seminare qui: `user_roles.user_id` punta a un utente
+-- di `auth.users`, che su un database appena creato non esiste ancora. Dopo il primo login
+-- (in locale come in produzione) basta una riga:
+--
+--   INSERT INTO public.user_roles (user_id, role)
+--   SELECT id, 'admin' FROM auth.users WHERE email = '<la tua mail>';