Fix intermittent Android MTU reconnect delay

[TobiasRoeddiger]

Android can lose an immediate MTU reply during reconnect, leaving the app waiting ten seconds before retrying. Pin the 2.3.0 backport of upstream universal_ble#307: register the waiter before the native request, deliver replies on the main looper, and keep negotiated MTU state scoped to the current connection.

This changes only the dependency override and lockfile. The upstream fix is merged but unpublished; the backport retains 2.3.0's existing command queue behavior. Remove the override when a suitable fixed version is published.

Validation:

• Both targeted race regressions fail on the original 2.3.0 sources; all 25 native tests pass with the backport.
• App analysis, all 135 app tests, and Android release build pass.
• Real Pixel 9a with both earphones: eight same-process reopen cycles and two force-stop/restarts all reconnect, each returning 48 fresh temperature samples per ear in six seconds. No MTU timeouts or app exceptions; negotiated MTU stays 498 bytes. A Bluetooth off/on cycle clears stale devices and reconnects both with another 48 fresh samples per ear.

The fresh four-cycle baseline also passed; the delay is intermittent and was captured in earlier phone logs. These checks do not claim a fixed percentage improvement in reconnect latency.

[github-actions]

PR Build Artifacts

• Android APK: Download Android APK
• Linux Bundle: Download Linux Bundle
• Windows Runner: Download Windows Runner
• Web Bundle: Download Web Bundle

Full workflow run: https://github.com/OpenEarable/app/actions/runs/37336503241

[github-actions]

Visit the preview URL for this PR (updated for commit 65ce8e7):

https://open-earable-web--pr338-codex-android-mtu-re-prtgayhj.web.app

_{(expires Mon, 02 Nov 2026 15:57:09 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

_{Sign: c7397c11177c71d8d81172cea9365829823fb41c}