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>

src/integrations/supabase/client-nuove-tabelle.ts

@@ -0,0 +1,12 @@
+import type { SupabaseClient } from "@supabase/supabase-js";
+import { supabase } from "./client";
+
+/**
+ * `types.ts` è generato dallo schema e non include ancora le tabelle introdotte dalle
+ * migration M1 (`giocatori_squadra`) e M2 (`profili_giocatore`). Finché non viene
+ * rigenerato si passa da qui: i tipi delle righe sono dichiarati nei moduli di `src/lib/`,
+ * che restano l'unico punto di accesso al database (DD-013).
+ *
+ * Da eliminare quando `types.ts` sarà rigenerato: i moduli torneranno a usare `supabase`.
+ */
+export const supabaseNuoveTabelle = supabase as unknown as SupabaseClient;