fix: banner flicker (WPB-23994)

[sbakhtiarov]

https://wearezeta.atlassian.net/browse/WPB-23994

https://wearezeta.atlassian.net/browse/WPB-23994

What's new in this PR?

Issues

On every app start, the "Decrypting messages" or "Waiting for network" banner flashed briefly in the top app bar, even when the device was online and sync completed quickly (under one second).

Causes (Optional)

Two independent bugs combined to produce the flash:

1. SyncState.Waiting was treated as a connectivity problem.
   Waiting is a pure pre-initialisation state — the sync worker has not been scheduled yet and carries no information about network health. Mapping it to WaitingConnection caused "Waiting for network" to appear immediately on every
   cold start, before sync even began.

2. The debounce operator was placed outside flatMapLatest.
   currentSessionFlow() is a plain SQLDelight Flow that can emit multiple Success values at startup, causing flatMapLatest to restart its inner flow repeatedly. The debounce operator sat outside this restart boundary, so timers from
   cancelled inner flows survived and fired with stale state — producing the "Decrypting messages" flash even after sync had completed.

Solutions

• Map SyncState.Waiting → Connectivity.Connected so no banner is shown during the pre-init window.
• Add a debounce inside connectivityFlow that holds Connecting/WaitingConnection for CONNECTIVITY_STATE_DEBOUNCE_DEFAULT (1 s) before emitting, but passes Connected through at 0 ms immediately. If sync or network recovers within the
  window, the timer is cancelled and no banner ever appears.
• Move the per-session debounce inside the flatMapLatest Success branch so it is cancelled together with its inner flow on session change. Connectivity states arrive here already debounced, so the per-session debounce only adds
  extra delay for the ongoing-call bar (600 ms, to absorb rapid mute/unmute changes without flickering). Everything else passes through at 0 ms.

[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

[MohamadJaara]

not sure how i feel about Map SyncState.Waiting → Connectivity.Connected i would much rather give it its own state to avoid issues and misunderstandings, like someone sees in the logs Connectivity.Connected but they can't send messages somehow