NetworkCallback onLost doesn't always fire before onAvailable

[growse]

Location: MQTTMessageProcessorEndpoint.kt:92-112

When switching from wifi to mobile data, Android's ConnectivityManager.NetworkCallback can deliver onAvailable (for mobile) before onLost (for wifi). This is documented Android behavior for registerDefaultNetworkCallback.

The sequence:

Mobile data becomes available → onAvailable() fires
State is still CONNECTED (on wifi), so the check endpointStateRepo.endpointState.value == EndpointState.DISCONNECTED at line 100 evaluates to false → no reconnect is attempted
Wifi is lost → onLost() fires → disconnect() is called → state becomes DISCONNECTED
No further onAvailable event fires because mobile data was already reported as available
Result: connection is stuck in DISCONNECTED state permanently

The Paho connectionLost() callback (line 297) might fire and schedule a scheduleMqttReconnect(), but if disconnect() from onLost closes the client cleanly first, Paho won't fire connectionLost — it only fires on unexpected disconnections.