fix(sync): recover after connectivity returns

[MohamadJaara]

Intent

Recover sync promptly when the app returns after a long offline period, and add Android consumer coverage for the foreground lifecycle behavior that triggers recovery.

Depends on Kalium PR #4310, which contains the retry and request-demand implementation.

Reproduction from the F-Droid device logs

1. Leave the device offline long enough for incremental sync retry delays to grow from seconds into minutes.
2. Reconnect Wi-Fi. Android reports the network before DNS is fully usable, so the immediate sync attempt can fail with UnknownHostException.
3. Open the app or toggle Wi-Fi again.
4. Sync remains on Waiting for network because the DNS failure inherited the old exponential delay and the new foreground request did not restart an already-requested failed sync.
5. Force-stop and reopen the app. The recreated process resets the stale state, opens the websocket, and completes sync.

What changed

• Update Kalium to reset retry backoff on a newly validated network and retry immediately.
• Restart failed sync when a new logical request arrives, including the request created when the app returns to the foreground.
• Keep state waiters separate from logical request demand so they cannot cause duplicate restarts.
• Extend the app test executor with active-request tracking.
• Cover foreground request recreation after a background transition.
• Cover adding a foreground request while a persistent sync request is already active.

Resulting behavior

• The first active logical request starts sync.
• Returning to the foreground creates a fresh logical request.
• If sync is already live, the new request leaves the connection alone.
• If sync is failed and backing off, the new request cancels that wait and retries immediately.
• A newly validated network also interrupts the wait and resets exponential state.
• If DNS is still warming up, the next retry starts from the minimum delay instead of inheriting a multi-minute delay.
• Sync stops when the last logical request ends; internal state waiters do not affect that lifetime.

Coverage

The Android tests verify both ordinary background-to-foreground request recreation and the persistent-request case that previously kept requester demand continuously non-zero.