chore(wip): consolidation intermédiaire multi-tickets (sprints Statistiques, UI, Bug resolution, Serveur-client)

Regroupe l'état de travail en cours réalisé dans un même worktree sur
plusieurs tickets/sprints (#85, #136, #145, #155-160, #162-164),
mélangeant des tickets QA et inProgress. Ne constitue pas une feature
terminée : commit de sauvegarde avant triage/split par ticket en
branches feature/* dédiées. Exclut les dossiers d'environnement de
build locaux et le heap dump parasite (.gitignore mis à jour).

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

.ideai/tickets/143/carnet.md

@@ -0,0 +1,15 @@
+---
+issueRef: "#143"
+version: 4
+updatedBy: {"kind":"agent","agent_id":"f3408f5d-469c-4f64-9485-d8b218f3ff26"}
+updatedAt: 1785143072501
+---
+## Cadrage UX (agent UX, 2026-07-27)
+
+**Nature** : trop exploratoire pour une implémentation immédiate — pas un ticket UX/dev prêt à l'emploi, mais une idée produit qui nécessite un spike de faisabilité technique d'abord.
+
+**Pourquoi** :
+- **GPS indoor** : la précision GPS grand public en intérieur (gymnase/salle) est dégradée (multipath, perte de signal), alors qu'un terrain de basket (~15×28 m) demanderait une précision de l'ordre du mètre pour qu'une hotmap ait du sens. Sans mesure terrain réelle de la précision obtenue avec une montre connectée, tout cadrage UX (comment dessiner/calibrer le terrain, comment afficher la hotmap) reposerait sur une hypothèse technique non vérifiée.
+- **Détection de shoot au gyroscope** : reconnaissance de geste non triviale (faux positifs probables : dribble, passe, contact défensif), nécessiterait un modèle/calibration, aucun précédent dans le projet.
+
+**Recommandation** : ne pas cadrer l'UX maintenant. Garder #143 en dormant comme idée produit, et proposer un ticket de spike technique séparé (Architect/DevMobile) : « Faisabilité GPS terrain + détection de shoot montre », avant tout travail UX. Le cadrage UX (création de terrain, affichage hotmap) ne devient exploitable qu'une fois la précision réelle mesurée.