« Fermer l'app Polar Flow » était un conseil faux, et mesuré tel dès le 31/08

Sylvain enchaîne un troisième envoi et reçoit « le canal est probablement
occupé » — notre propre message, déclenché par watchNotFound avec des montres
muettes : le service PsFTP est là, il ne répond pas.

La chronologie de ses trois envois explique tout. Le premier réussit, montre
fraîchement réinitialisée donc pas encore liée à Flow. Le deuxième renvoie 104
DIRECTORY_EXISTS, ce qui prouve que le canal était ENCORE libre. Le troisième
échoue : Flow a repris la main entre-temps. Le canal n'est donc pas ouvert ou
fermé en général — il y a une fenêtre, qui se referme dès que Flow se
reconnecte.

Le message conseillait de fermer complètement l'app Polar Flow. C'était faux, et
la mesure du 31/08 le disait déjà : la montre affichait « connexion impossible »
pendant que les réglages iOS la disaient toujours connectée à Flow. iOS maintient
le lien d'un accessoire appairé, app fermée ou non. Le message nomme maintenant
le geste qui libère réellement le canal — redémarrer la montre — précise que
fermer l'app n'y change rien, et rappelle que le câble est le chemin fiable.

Corrigé au passage le message des appareils sans PsFTP, qui présentait encore la
question comme « l'inconnue restante » alors qu'elle a été tranchée le 31/08 :
la montre expose bien PsFTP quand elle est connectée. Un test interdit désormais
de la rouvrir dans l'UI.

88 tests Linux verts, dont deux nouveaux qui verrouillent l'absence du conseil
inutile et la présence du geste utile.

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

docs/polar-ble-runbook-mac.md

@@ -383,3 +383,33 @@ documentée et devra être mesurée.
 **câble**.
 
 [ancs]: https://developer.apple.com/library/archive/documentation/CoreBluetooth/Reference/AppleNotificationCenterServiceSpecification/Specification/Specification.html
+
+### La séquence du 01/09, et ce qu'elle apprend sur la fenêtre
+
+Trois envois consécutifs, trois résultats différents — c'est la chronologie qui
+explique tout :
+
+| # | résultat | lecture |
+|---|---|---|
+| 1 | **réussi** | montre fraîchement réinitialisée, **pas encore liée à Flow** : canal libre |
+| 2 | **errorcode 104** `DIRECTORY_EXISTS` | canal **toujours** libre, la session s'ouvre — seul le `mkdir` bute sur un dossier déjà créé au 1ᵉʳ envoi |
+| 3 | **« canal probablement occupé »** | Flow a repris la main entre-temps |
+
+⇒ Le canal n'est pas ouvert ou fermé « en général » : il y a une **fenêtre**,
+qui commence quand la montre n'est liée à personne et se referme dès que Flow
+se reconnecte. C'est cohérent avec le 31/08 et avec l'USB, où il faut fermer
+Flow.
+
+⚠️ **Le message d'erreur du plugin conseillait « fermer complètement l'app Polar
+Flow ». C'est faux, et ça l'était déjà le 31/08** : la montre affichait
+« connexion impossible » pendant que les réglages iOS la disaient **toujours
+connectée** à Flow. iOS maintient le lien d'un accessoire appairé, app fermée ou
+non. Message corrigé le 01/09 — il nomme désormais le geste qui libère
+réellement le canal (redémarrer la montre) et rappelle que le câble est le
+chemin fiable.
+
+**Hypothèse ouverte, non vérifiée** : redémarrer la montre puis écrire *dans la
+foulée*, avant que Flow ne se reconnecte, pourrait suffire. Ça expliquerait les
+envois 1 et 2. Ce n'est pas une méthode tant que ça n'a pas été reproduit
+plusieurs fois — et ⛔ chaque essai a un coût matériel avéré (l'USB désactivé le
+31/08). **Écrire la séance par câble AVANT tout essai.**