[bug]: WB relatch enters liveness reconnect loop after server restart

[BM-BUROMIR]

Problem

WB/vp8channel can relatch after a forced server-side restart, but the post-restart session can fall into a liveness / carrier reconnect loop instead of stabilizing.

Observed behavior from iOS field testing:

• the client does create fresh sessions after the WB server side is restarted;
• those new sessions are unstable;
• server-side liveness can close the newly opened session repeatedly;
• the carrier reconnect limit may be reached.

Current hypothesis

This should be handled in the olcrtc core relatch state machine, not in the iOS host app.

The fragile area couples:

• VP8 single-peer data/control epoch reset;
• server-side smux/control liveness;
• stale peer session/runtime cleanup;
• WB/LiveKit carrier reconnect callbacks and reconnect-limit behavior.

Suggested direction

• define the authoritative owner of the current live session on server and client;
• ensure stale liveness handlers cannot close newly opened sessions;
• separate carrier reconnect lifecycle from smux liveness lifecycle;
• define when VP8 epochs rotate/reset/request reconnect;
• add an integration-style test: old WB server dies, same client process relatches to new server and keeps control alive.

Related

• BM iOS/client tracking was moved out of BM-BUROMIR/olc-amnezia-client#5 because this is a core olcrtc behavior.
• BM release candidate: BM-BUROMIR/olcrtc#1.