Android: fix lost MTU completions and reconnect isolation

[featzima]

Android reconnects can report onMtuChanged(247, GATT_SUCCESS) while the Dart requestMtu future still times out. In the existing implementation, the waiter is registered after the native request, the pending list is accessed from both the platform and Binder threads without synchronization, and an MTU reported before the request is discarded.

This registers the waiter before calling Android, synchronizes pending-request completion, and delivers replies on the main looper consistently with the other BLE completion paths. It also handles native rejection immediately and coalesces requests already pending for the same GATT client.

Negotiated MTUs are retained per GATT client, so a reconnect cannot reuse an old connection's value or consume its late callback. The actual observed MTU is returned, including values smaller than requested. Android 13 and earlier can still request an increase; Android 14+ reuses the observed value because subsequent MTU requests are ignored. Disconnect clears the cached value and fails pending requests.

Validation:

• Android native tests: 23 passed, including 11 MTU cases covering early callbacks, duplicate delivery, already negotiated MTU, native rejection, disconnect and stale reconnect callbacks. Run with Java 17 / Gradle 8.14.3 using the example project.
• Flutter tests: 109 passed.
• Chrome tests: 105 passed.
• Package and HIL analysis: passed with fatal infos enabled.
• Physical regression in a consuming app on a Pixel 6a (Android API 37): three background reconnect/read/disconnect cycles completed at MTU 247 without timeouts, followed by successful foreground recovery. This hardware check used the 2.3.0-based patch before porting it to current main; the API 37 MTU path is unchanged.

The native API and generated Pigeon files are unchanged.