fix(sessions): stop the Hub background-refresh re-render loop

[RonenMars]

Closes #564 and #565.

Problem

On-device tracing of the Hub while it shows "Showing cached data — syncing" (both servers paired) found ProjectsHub re-rendering continuously — hundreds of commits at ~6/sec during warm-up, never settling.
A per-commit "why did this render" probe attributed the churn to two independent sources, neither addressed by the throttle/memo work in #563.

Fixes

1. serverFetchStatus store (serverFetchStatus store re-renders subscribers on every HTTP response (fresh object on unchanged status) #564): recordSuccess/recordReady allocated a new statuses object with a fresh Date.now() on every successful HTTP response, even when the status was already ok, so every API call re-rendered every subscriber.
   Both now return the same state when nothing changed, so zustand does not notify — recordReady still clears warming_up → ok.
2. refreshEagerConversations (conversation_updated WS frames trigger a full eager-conversations re-drain per frame (sustained Hub re-render loop) #565): every conversation_updated WS frame invalidated the whole conversations-eager query, re-draining every page of every server per liveness ping.
   It is now debounced (trailing 1s) so a burst of frames collapses into a single re-drain.
   The long-term follow-up noted in conversation_updated WS frames trigger a full eager-conversations re-drain per frame (sustained Hub re-render loop) #565 is to patch the single affected conversation in the eager cache instead of re-draining everything.

Verification

Unit: 12 tests pass across serverFetchStatus and eagerCacheSync, including new cases for same-identity no-op writes, warming_up → ok still clearing, and debounce/coalesce behavior.
On-device (iOS simulator, two real servers, EXPO_PUBLIC_OPEN_TRACE=1): render rate dropped from ~6/sec to ~0.65/sec and fetchStatuses disappeared from the render-driver breakdown after the store guard.