feat: onboarding multi-step per la scelta dello sport (bozza incompleta) #45

Stato: BOZZA. Ticket volutamente incompleto. Non implementare finché non viene completato: raccoglie la decisione di prodotto già presa e lascia aperti i punti che richiedono il design multi-step.

Decisione già presa

Lo sport attivo è uno stato di sessione, non un filtro di ricerca:

• l'utente lo sceglie e vale per tutta la sessione;
• ogni sorgente dati viene filtrata a monte (mappa/campi, lobby, ricerca), così le richieste al server trasportano solo ciò che serve e la UI non si sovraccarica;
• i campi con sport = 'multi' restano visibili sotto qualunque sport;
• la scelta è persistita lato client e sopravvive al reload.

Cosa aggiunge questo ticket

La prima esperienza: un onboarding multi-step che possiede la scelta iniziale dello sport, invece del default silenzioso basket + selector sempre visibile che esiste oggi come ripiego.

Aperto (da decidere quando si farà)

• Numero e contenuto degli step oltre allo sport (posizione? notifiche? nickname?).
• Se l'onboarding è bloccante o skippabile, e cosa succede a chi lo salta.
• Dove vive lo stato "onboarding completato" (profilo utente lato DB vs localStorage) e cosa succede con utente anonimo che poi accede.
• Se la scelta dello sport fatta in onboarding è modificabile dopo, e da dove.
• Copy e microcopy degli step, in italiano.
• Comportamento su PWA installata e primo avvio offline.

Dipendenze

• Phase 1 (data growth) consegna il selettore sport di sessione, il contesto client persistito e il filtraggio di mappa/lobby/ricerca: senza quello, questo ticket non ha fondamenta.
• Il cambio radicale di navigazione/UX è esplicitamente possibile in futuro: i componenti del selettore sport vanno tenuti standalone, non cablati nel layout della home.