Le scan du SDK ne démarre pas, et le message le dira au lieu d'accuser la montre

43 appareils vus par un scan CoreBluetooth nu, 0 remonté par le SDK Polar. La
radio, l'autorisation et la montre sont hors de cause — c'est notre usage du SDK.

Trois suspects écartés sur les sources plutôt que supposés, et écrits dans le
runbook pour que personne ne les revérifie : servicesToScanFor à nil est aussi
ce que fait PolarBleApiImpl ; un scanPreFilter nil ACCEPTE les appareils (le
`if let` échoue, le rejet est sauté) ; et addClient() suffit à lancer le scan,
scanningNeeded() rendant vrai dès que clientCount != 0.

Reste une hypothèse : search() commence par
`monitorBleState().filter { $0 == .poweredOn }`. Si cet état n'arrive jamais, le
publisher ne dit RIEN — ni valeur, ni complétion, ni erreur — et le timeout
conclut « aucun appareil » alors qu'on n'a jamais cherché. Ce sont deux
diagnostics opposés que le même message couvrait.

L'instrumentation note donc si le publisher a parlé, et relaie une éventuelle
erreur du SDK telle quelle. Trois messages distincts en sortent, trois tests les
verrouillent.

Piste notée pour la reprise : le SDK pose powerStateObserver et
deviceSessionStateObserver sur son listener et passe identifier: 0 ; nous ne
posons aucun observateur et passons 1.

80 tests au vert sur tests-linux.

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

docs/polar-ble-runbook-mac.md

@@ -119,10 +119,38 @@ réussi : écrire un objectif daté 18 h et regarder s'il apparaît immédiateme
 - S'il n'apparaît qu'à l'approche → il faut écrire à l'heure du départ. Sans
   conséquence pratique : l'envoi se fait de toute façon juste avant de sortir.
 
+## 🔴 Où ça bloque au 31/08 : le scan du SDK ne démarre pas
+
+Mesuré, pas supposé : **43 appareils vus par un scan CoreBluetooth nu, 0 remonté
+par le SDK Polar.** La radio, l'autorisation et la montre sont donc hors de
+cause — le problème est dans notre usage du SDK.
+
+Ce qui a été écarté **sur les sources**, pour ne pas le refaire :
+
+- `servicesToScanFor` à `nil` : c'est aussi ce que fait `PolarBleApiImpl`.
+- `scanPreFilter` à `nil` : **accepte** les appareils. La condition est
+  `if self.session(peripheral) == nil, let filter = self.scanPreFilter` — sans
+  filtre, le `if let` échoue et le rejet est sauté.
+- `addClient()` suffit à lancer le scan : `scanningNeeded()` rend vrai dès que
+  `clientCount != 0`, aucune action « admin » n'est requise.
+
+**L'hypothèse qui reste**, et que l'instrumentation ajoutée doit confirmer :
+`search()` commence par `monitorBleState().filter { $0 == .poweredOn }`. Si cet
+état n'arrive jamais, le publisher ne dit **rien** — ni valeur, ni complétion,
+ni erreur — et le timeout conclut « aucun appareil » alors que le scan n'a
+jamais démarré. Le message distingue désormais ce cas (« le SDK n'a jamais
+signalé que le Bluetooth était prêt ») des autres.
+
+⚠️ **Piste à explorer en premier à la reprise** : le SDK positionne
+`powerStateObserver` et `deviceSessionStateObserver` sur son
+`CBDeviceListenerImpl`, et passe `identifier: 0`. Notre code ne pose aucun
+observateur et passe `identifier: 1`. Vérifier si `monitorBleState()` dépend
+d'un de ces réglages.
+
 ## Ce qui reste inconnu, et ne se lèvera qu'ici
 
 1. **La V3 accepte-t-elle une connexion BLE tierce** alors qu'elle est appairée
-   à l'app Flow ? Jamais testé. C'est le risque principal.
+   à l'app Flow ? Toujours pas testé — on n'a pas encore atteint la montre.
 2. **Le filtrage de la montre** se fait sur « expose le service PsFTP (FEEE) »,
    pas sur le nom : ce que la V3 met dans son advertisement n'a pas été observé,
    et s'appuyer dessus aurait été une supposition. À resserrer une fois vu. Un