Document transport selection (§15): single-mode queries, BLE provisions Wi-Fi

docs/RE_DART_FINDINGS.md

@@ -316,6 +316,24 @@ port **18000**. Port `9000` appears nowhere in the app; `18000` is closed
 on the tested unit, so even the app's own socket path cannot work there —
 consistent with all-silent probes.
 
+## 15. Transport selection — one mode at a time, BLE provisions Wi-Fi
+
+- `DirectConnectProvider.initSelectedMode`: on the FHP AP → `socket`;
+  otherwise, if a BLE device is connected (or a previous selection exists)
+  → `bluetooth` (+ `initScan`); else `socket`. Every request carries its
+  transport in `selectedMode` (`field_5b`); `sendObjectOrganized` routes to
+  exactly one manager. Queries never run on both transports at once.
+- Switching AP → socket explicitly tears down BLE first
+  (`onSelectHotspot`: `disconnectBluetooth` behind the
+  `switchBluetoothToHotspotTip` dialog).
+- `directConnect()` (provider and service variants) is true when on the FHP
+  AP **or** BLE-connected — the two are alternative routes to one device.
+- BLE and Wi-Fi *cooperate* at the commissioning layer, not the query
+  layer: ESP BLE provisioning (`prov-session/scan/config`, sec0/sec1)
+  delivers the home Wi-Fi SSID/password to the device **over BLE**; the
+  socket/HTTP hotspot APIs (`/terminal/*`, `wifi_iot` join) take it from
+  there. Same envelope + cipher on both transports (§5, §9).
+
 ## 9. Bluetooth (BLE) transport — `communication_center/bluetooth`
 
 - `BluetoothManager` (singleton), `BluetoothStatus`: `closed / connected / connecting / interrupted`.