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/127/carnet.md

@@ -0,0 +1,28 @@
+---
+issueRef: "#127"
+version: 9
+updatedBy: {"kind":"user"}
+updatedAt: 1785216992076
+---
+
+## #127 — Avis UX bref (2026-07-27)
+
+Pas une question de conception : le comportement attendu ne fait aucun doute (l'utilisateur doit retrouver l'écran d'exécution exact, pas le launcher, après ré-allumage par mouvement de poignet). C'est un bug de cycle de vie Wear OS (probable absence de gestion Ambient Mode / activité tuée au lieu d'assombrie). Recommandation : implémenter le mode Ambient (écran assombri, app conservée) plutôt que laisser le système détruire l'activité ; au réveil, restituer l'état exact sans flash de chargement. Prêt pour implémentation directe (Architect/DevFrontend), aucun arbitrage UX supplémentaire nécessaire.
+
+---
+
+## Cadrage technique Architect (2026-07-27)
+
+**Root cause confirmée dans le code réel** : `watch_app/android/app/src/main/kotlin/com/gametime/watch/MainActivity.kt` est une `FlutterActivity` nue, sans aucune gestion Ambient (`AmbientModeSupport`/`AmbientLifecycleObserver` absents), et le manifest (`watch_app/android/app/src/main/AndroidManifest.xml`) ne déclare aucune capability ambient. Sans ambient mode, Wear OS **détruit l'activité** à l'extinction de l'écran plutôt que de la conserver assombrie ; au réveil (mouvement de poignet), le système relance le launcher/watch face au lieu de restaurer l'app — exactement le symptôme rapporté.
+
+### Contrat technique
+- Dépendance : `androidx.wear:wear-ambient` dans `watch_app/android/app/build.gradle.kts` (actuellement seule dépendance wear présente : `play-services-wearable:19.0.0`, sans rapport avec l'ambient).
+- `MainActivity` doit implémenter `AmbientModeSupport.AmbientCallbackProvider` et appeler `AmbientModeSupport.attach(this)` dans `onCreate` — cela maintient l'activité en vie (assombrie) à l'extinction de l'écran, au lieu de la laisser être détruite par le système.
+- **Aucune reconstruction d'état nécessaire au réveil** : l'architecture existante s'y prête déjà — `WatchWearDataLayerAdapter._nativeChannel.connectionEvents` déclenche `emitCurrentProjection()` sur `isReachable`/`requestsResync`, et le `_ensureProjectionRefreshLoop` republie toutes les 2s (cf. audit #126 dans ce même lot d'audit). Tant que l'activité Flutter reste résidente pendant l'ambient (au lieu d'être tuée), l'état affiché au réveil est déjà à jour sans code de restauration supplémentaire à écrire.
+- Ne pas suivre la voie `ExerciseClient`/mode "exercise" système (déjà écarté par le cadrage #124 pour la collecte capteurs, même raison ici : GameTime ne doit pas déclarer un second concept de session au niveau OS).
+- Vigilance batterie : en ambient, limiter les rebuilds au strict nécessaire (le `Timer.periodic(1s)` déjà présent dans `watch_session_screen.dart` pour l'interpolation locale des chronos peut continuer sans changement — c'est un `setState` léger, pas un accès réseau/capteur).
+
+### Tests
+Non testable en sandbox (cycle de vie Android natif, cohérent avec la contrainte déjà connue pour les autres services natifs watch, cf. [[gametime-watch-companion-implementation]]) — validation manuelle on-device requise : écran éteint puis rallumé par mouvement de poignet pendant une séance active, vérifier que l'app reste au premier plan sur l'écran d'exécution exact (pas de flash de chargement, pas de retour au launcher).
+
+**Prêt pour implémentation directe, aucun arbitrage supplémentaire nécessaire.**