fix(ble): cleanup races discovered while reviewing #5207

[jamesarich]

Two follow-up cleanup races found while reviewing the GATT-133 reconnect fix in #5207. Both are latent today (narrow timing windows) but become more likely under aggressive reconnect / multi-device scenarios.

Changes

• KableBleConnection.connect() ownership install — Kable allocates a per-peripheral coroutine scope and Bluetooth-state observer eagerly when Peripheral(...) is constructed. Cancellation between peripheral construction, field assignment, and ActiveBleConnection.active = … could strand the new peripheral with no field referencing it for cleanup. Wrap the three-step ownership install in withContext(NonCancellable). _deviceFlow.emit() is intentionally left outside the block to avoid hanging teardown on a slow collector.

• KableBleConnection.disconnect() identity check — disconnect() cleared ActiveBleConnection.active unconditionally. A stale disconnect from an earlier connection attempt's exception handler running after a newer connection had installed itself as active would clobber the newer entry. Capture the owned peripheral at the start of disconnect() and only clear ActiveBleConnection if it still references that same instance.

• BleRadioTransport exception handler cleanup scope — the CoroutineExceptionHandler on connectionScope launched its last-ditch bleConnection.disconnect() on the per-transport scope. When upper layers tear scope down in response to the same uncaught exception that triggered the handler, scope.launch can fail to start at all, defeating the cleanup and leaking BluetoothGatt (status 133 on the next reconnect). Use a dedicated cleanupScope built from scope's context minus its Job plus a fresh SupervisorJob so the cleanup launch is independent of the parent's cancellation state. Cancelled in close() once our own disconnect completes.

Verification

• ./gradlew :core:network:spotlessApply :core:ble:spotlessApply :core:network:detekt :core:ble:detekt ✅
• ./gradlew :core:network:allTests :core:ble:allTests ✅

Follow-up to #5207.