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

@@ -0,0 +1,30 @@
+---
+issueRef: "#132"
+version: 8
+updatedBy: {"kind":"user"}
+updatedAt: 1785141275322
+---
+
+## #132 — Avis UX bref (2026-07-27)
+
+Décision simple : rendre le geste symétrique. Si swipe gauche (séance → actions) existe déjà comme pager horizontal, activer le swipe droit (actions → séance) sur ce même pager plutôt que d'exiger le tap. Garder le bouton existant en complément (pas de régression pour qui ne découvre pas le geste) — pas un remplacement, une addition. Aucun nouveau libellé ni état à concevoir. Prêt pour implémentation directe.
+
+---
+
+## Cadrage technique Architect (2026-07-27)
+
+**Root cause probable identifiée** — conflit avec le geste système Wear OS, pas un bug applicatif Flutter classique.
+
+`watch_session_screen.dart` utilise déjà un `PageView` standard (`_pageController`, ligne 18-24, `PageView` ligne 52) avec deux pages : session (index 0) et actions (index 1). Un `PageView` Flutter standard est **nativement bidirectionnel** — rien dans `_ActionsView` (`lib/presentation/watch_session_screen.dart:638` et suivants) ne bloque le swipe : ce sont des `OutlinedButton` en pleine largeur dans un `Column`/`Stack`, aucun `GestureDetector`/scrollable horizontal imbriqué qui capturerait le drag avant le `PageView`.
+
+Donc l'asymétrie observée (swipe gauche marche, swipe droit ne marche pas) ne vient probablement pas du code Flutter, mais du **geste système Wear OS "swipe to dismiss"** : par défaut, Android Wear réserve la zone de bord gauche de l'écran pour un swipe-vers-la-droite (glisser le doigt de gauche à droite en partant du bord) interprété comme "retour/dismiss" au niveau de la fenêtre native, **avant** que Flutter ne reçoive le geste. Aucune configuration n'a été trouvée dans `watch_app/android/app/src/main/res/values*/styles.xml` (`windowSwipeToDismiss` absent, donc comportement par défaut du thème actif). C'est cohérent avec le symptôme précis : seul le swipe *partant du bord gauche vers la droite* est absorbé par le système, pas le swipe gauche (séance→actions) qui part du centre/droite de l'écran vers la gauche.
+
+### Contrat technique (à valider on-device par DevFrontend, deux pistes par ordre de préférence)
+1. **Désactiver le swipe-to-dismiss système sur cet écran** pour laisser le geste au `PageView` applicatif : `android:windowSwipeToDismiss="false"` sur le thème de `MainActivity` (`styles.xml`), ou gestion explicite via `OnBackInvokedCallback`/`BackHandler` si l'app cible l'API de predictive-back. Cohérent avec le fait que GameTime n'a pas besoin du dismiss système ici : le bouton retour physique/couronne reste la sortie d'app standard, le swipe droit devient un geste de navigation interne au pager.
+2. Si la contrainte OS empêche de désactiver complètement le dismiss (à vérifier on-device), alterative : ne pas ancrer `_ActionsView` sur le bord gauche de l'écran (ex. léger padding gauche pour que le point de départ du swipe utilisateur naturel soit hors de la zone système réservée) — solution de repli, moins propre, seulement si l'option 1 s'avère impossible.
+- Garder le bouton `IconButton`/`chevron_left` existant (ligne 673-681) en complément, conformément à l'avis UX ci-dessus — c'est déjà le cas, aucun changement requis sur ce point.
+
+### Tests
+Non testable en sandbox (comportement de geste système natif Wear OS, cohérent avec les autres limites déjà connues, cf. [[gametime-watch-companion-implementation]]) — validation manuelle on-device requise : swipe droit depuis l'écran actions doit revenir sur l'écran session, sans déclencher de dismiss/sortie d'app.
+
+**Prêt pour implémentation directe. Un point à vérifier on-device par DevFrontend avant de considérer le correctif complet** : confirmer que la piste 1 (`windowSwipeToDismiss=false`) ne réintroduit pas de régression sur la sortie d'app via bouton retour physique — pas un arbitrage produit, une vérification technique de mise en œuvre.