Le snapshot arrive à la montre, et on peut enfin le dire

Vérifié sur l'iPhone de Sylvain le 24/09, après build :

    Montre : snapshot reçu
    Zones envoyées : version frozen du 2026-08-12

Les quatre causes d'échec silencieux du § 1.2 sont écartées — session activée,
montre appairée, app Watch installée, updateApplicationContext sans erreur — et
la date de version arrive au poignet, elle qui se perdait au transport. C'est la
première fois que ce chemin peut être affirmé plutôt que supposé : il était muet
depuis son écriture.

⚠️ Ce que ça ne prouve pas, et c'est écrit dans le document :
`updateApplicationContext` est asynchrone. iOS a ACCEPTÉ le contexte, il le
livre quand il peut. Ce qui est établi, c'est que l'iPhone a réussi à le
transmettre au système — pas que la montre affiche les bonnes bornes. Seul le
poignet le dira, pendant une séance.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/DIAGNOSTIC-NATIF-2026-09-24.md

@@ -6,10 +6,22 @@
 > est décrit en fin de document, § « Ce qui a été corrigé ». **Les quatre autres
 > constats restent ouverts, et le gel tient pour eux.**
 >
-> ⛔ **Rien n'est réel tant que le build Mac n'a pas tourné.** Syntaxe vérifiée
+> ✅ **BUILD FAIT ET VÉRIFIÉ SUR L'APPAREIL, le 24/09.** Le diagnostic de
-> (`swiftc -parse`) et 91 tests du banc Linux verts — mais ni `CoachWidgetBridge`
+> `/settings` (« Diagnostiquer et pousser ») affiche sur l'iPhone de Sylvain :
-> ni `HeartRateZones` ne se compilent hors Xcode : Capacitor, WatchConnectivity
+>
-> et SwiftUI sont absents de Swift pour Linux.
+> ```
+> Montre : snapshot reçu
+> Zones envoyées : version frozen du 2026-08-12
+> ```
+>
+> Les quatre causes d'échec silencieux sont donc écartées : session activée,
+> montre appairée, app Watch installée, `updateApplicationContext` sans erreur.
+> Et la date de version arrive au poignet — elle se perdait au transport.
+>
+> ⚠️ **Ce que cela ne prouve pas** : `updateApplicationContext` est asynchrone.
+> iOS a *accepté* le contexte, il le livre quand il peut. Ce qui est établi,
+> c'est que l'iPhone a réussi à le transmettre au système — pas que la montre
+> affiche les bonnes bornes. Seul le poignet le dira, pendant une séance.
 
 **24/09/2026. Diagnostic mené en lecture seule** — aucune ligne de Swift n'avait
 été modifiée à sa rédaction.
@@ -310,6 +322,9 @@ zones sans date. La doublure `HeartRateZonesStub.swift` est tenue à l'identique
   affichable est un choix produit, pas une correction de défaut.
 - **Il ne touche pas au flux course à pied** (WorkoutKit, live workout FC, app
   Exercice), conformément à la consigne du 22/09.
-- **Il n'a pas été compilé.** Le geste qui vaut preuve, au prochain build :
+- ✅ **Compilé et vérifié le 24/09** — sans Console : le diagnostic de
-  ouvrir la Console sur la catégorie `widget` et vérifier qu'une ligne
+  `/settings` rend le statut en clair (`Montre : snapshot reçu` · `Zones
-  `snapshot poussé vers la Watch · zones=oui depuis=…` apparaît au lancement.
+  envoyées : version frozen du 2026-08-12`), parce que le plugin remonte
+  désormais `watchPushed` / `watchReason` jusqu'au JS.
+  ⏳ **Reste à voir au poignet** : que la montre affiche ces bornes pendant une
+  séance. L'envoi est accepté par iOS ; la livraison est asynchrone.