Keep group call tracks synchronized during reconnection

[phucnguyen1707]

Problem

In web-hosted P2P calls, a temporary media disconnection maps a viewer to reconnecting. Relay, screen publish and screen unpublish skipped that viewer, and returning to connected did not replay the missed changes. In a three-person call this can leave a viewer without another participant's audio after recovery, or with stale screen-share state.

Fix

• Include reconnecting in the three existing track-update filters.
• Continue using the existing per-viewer offer queue, generation checks and sender ownership; do not add recovery-time duplicate senders.
• Keep failed/closed cleanup, mute policy and microphone permissions unchanged.
• Add 11 regressions covering relay arrival, pending negotiation, muted replacement, source leave, screen publish/replace/unpublish and failed/closed peer lifecycle.

Validation

• Before the fix: 6 new regressions fail, 32 host tests pass. After: all 38 host tests pass.
• Full web suite: 84 files, 896 tests pass. Web typecheck, changed-file ESLint, Prettier and diff checks pass.
• Local Chromium with real RTCPeerConnection/SDP/RTP, one host and two viewer peers: the baseline misses the relayed audio, the patched hook receives both audio RTP streams. Screen publish/replacement/unpublish and source departure preserve the expected remaining audio. Repeated successfully.
• Exact final diff reviewed and approved by Claude Opus.

Scope and limits

The browser smoke test uses synthetic audio, in-page signaling and an injected disconnected media state. It is not a real WAN outage, production Supabase, SFU, mobile/native or all-browser validation. No production call or cloud build was triggered.

This addresses a reproduced cause of multiparty failure, not a claim that every symptom in the broad "more than 2 participants" report is resolved. Lost signaling/answers, terminal ICE failure recovery and other SFU paths remain separate investigations. This PR is independent of mobile microphone PR #105.