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

@@ -0,0 +1,39 @@
+---
+issueRef: "#125"
+version: 2
+updatedBy: {"kind":"agent","agent_id":"f8f40941-ecf7-4830-b9de-8818a099f448"}
+updatedAt: 1785127016437
+---
+
+## Audit DevFrontend — 2026-07-27
+
+- Correctif déjà présent dans le worktree : émissions `EventChannel` postées sur le main thread côté téléphone et montre.
+- Requête de projection Wear OS avec authority wildcard déjà présente.
+- Rafraîchissement projection téléphone périodique déjà présent pour réaligner la montre quand une séance démarre depuis le téléphone.
+- Aucun changement UI supplémentaire nécessaire sans nouvelle reproduction.
+
+À valider sur device : démarrage d'une séance depuis le téléphone, affichage montre non noir, puis réception des transitions séance/repos/actions.
+
+## Correctif QA DevFrontend — 2026-07-27
+
+- Le test widget 192x192 confirme maintenant le passage `no-session` vers contrôles score manuel sans écran noir ni overflow.
+- Correction associée : interpolation chrono basée sur `referenceEpochMs`, ce qui stabilise l'affichage quand la projection de test ou sync porte une référence temporelle distincte de `startedAtEpochMs`.
+- Build APK debug montre validé après réalignement du build dir Gradle sur le chemin attendu par Flutter.
+
+## Correctif DevFrontend — 2026-07-26
+
+- Cause frontend traitée avec #107 : la vue active pouvait remplacer la projection par un écran de connexion séparé et empiler trop de contrôles dans la zone ronde, rendant le rendu fragile au moment du passage hors `noActiveSession`.
+- Correctif : la projection de séance reste toujours rendue ; en perte de connexion elle est seulement assombrie avec indicateur `Connexion au téléphone perdue`.
+- Le layout actif est maintenant contraint et non scrollable, avec valeur dominante `FittedBox` et textes tronqués, ce qui évite une rupture de rendu lors du démarrage depuis le téléphone.
+- Vérification : `flutter analyze` watch_app OK ; build APK debug montre OK via Gradle/JDK 21.
+
+---
+
+## Audit Architect — revue du correctif (2026-07-27)
+
+Statut : **correctif confirmé comme root-cause fix, pas un patch cosmétique**. Vérification faite sur le diff réel de `watch_app/lib/presentation/watch_session_screen.dart`.
+
+- Cause racine confirmée : `_RoundScaffold` utilisait `SafeArea(minimum: ...) + Center + ConstrainedBox(maxWidth/maxHeight: 210)` sur un cadran rond — pattern classique de crash `RenderFlex overflow`/assertion de contraintes infinies au moment où le contenu bascule de l'état "aucune séance" (compact) à l'état "séance active" (plus riche : chrono, actions, bientôt score). Le correctif remplace ça par un `LayoutBuilder` qui dérive `contentSize` de `constraints.biggest.shortestSide`, ce qui élimine la classe d'erreur, pas seulement un symptôme.
+- **Aucun deuxième risque latent identifié** malgré l'ajout simultané des champs de score (`hasManualScore`/`currentManualScoreValue`/`canDecrementScore`, cf. #119) sur la même `WatchSessionProjection` que cet écran consomme : les trois champs ont des défauts sûrs en constructeur et en `fromJson`, tous les accès dans l'écran sont null-safe, et aucune nouvelle valeur d'enum (`WatchSessionPhase`/`WatchTimerKind`) n'a été ajoutée — donc aucun `switch` existant n'est rendu non-exhaustif par ce chantier parallèle.
+- **Garde-fou adjacent déjà fermé, à noter pour ne pas le rouvrir par erreur** : le diff inclut aussi un fix côté téléphone dans `WatchBridgePlugin.kt` (`android/app/src/main/kotlin/com/gametime/app/watch/`) postant les appels `EventChannel.EventSink.success(...)` sur `Handler(Looper.getMainLooper())` — appeler ces méthodes hors thread principal aurait pu être une seconde cause plausible d'instabilité autour du démarrage de séance ; déjà corrigé dans ce même diff, à ne pas régresser lors d'un futur refactor du plugin.
+- **Definition of done** : cause + correctif tiennent la route architecturalement. Il reste, comme indiqué par DevFrontend, le build/installation on-device pour la validation finale (non re-vérifiable en sandbox, cohérent avec la contrainte connue, cf. [[gametime-watch-companion-implementation]]) — aucun blocage architecture supplémentaire de mon côté.