Medtrum: Improve BLE connection recovery using handler thread

[HuismanErik]

This PR resolves "Pump unreachable" issues where the Medtrum driver stays stuck in the CONNECTING state, often following a GATT status 133 error. While other drivers (like Dash) recover correctly on the same hardware, the Medtrum implementation can fail to trigger mCallback?.onBLEDisconnected(). This causes the QueueWorker to stall and skip new connection attempts.

The root cause is performing a close() and state updates directly on the Bluetooth callback (Binder) thread, which can lead to deadlocks or silent connection stalls. Wrapping the GATT cleanup and state updates in a Handler.post() ensures these operations are executed asynchronously. This allows the onConnectionStateChange thread to finalize its lifecycle without being blocked.

In my testing, this change eliminated the "Pump unreachable" connection issues on my Xiaomi device. Additional testing by other Medtrum users would be appreciated to confirm correct behavior across different Android devices.

[MilosKozak]

any testers?

[jbr7rr]

Setting these 2 flags async can cause race conditions

[jbr7rr]

Before applying this fix, did you test with scanning enabled? This setting:
https://androidaps.readthedocs.io/en/latest/CompatiblePumps/MedtrumNano.html#scan-on-connection-error

This usually takes care of hardware specific connection issues

[jbr7rr]

Before applying this fix, did you test with scanning enabled? This setting:
https://androidaps.readthedocs.io/en/latest/CompatiblePumps/MedtrumNano.html#scan-on-connection-error

This usually takes care of hardware specific connection issues

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[HuismanErik]

Addressed the race condition raised by @jbr7rr: moved the flag resets into close() itself, which is already @Synchronized, so state is always updated with the GATT cleanup.

Regarding "scan on connection error": I tested this but it didn't help. The issue seems to be related to a stall on the Binder thread on some specific devices, which prevents onBLEDisconnected() from ever firing — scanning more aggressively didn't fix that.