Both users starting a call in the same DM at once collapsed both attempts: two useSwitchOrStartDmCall instances (header outgoing + strip answer) race on the shared callEmbedAtom, the counter-ring surfaces during the outgoing embed's forming window, and answering it disposes+recreates the embed — putting two MembershipManagers on one (user,device) state-key, driving the SDK 'Missing own membership: force re-join' thrash. Fix per MatrixRTC canon (a call is co-presence, there is no 'answer'): a formingCallRoomIdAtom set synchronously before the outgoing awaits marks the room as forming; an incoming call for a room we already hold/are forming becomes a no-op (element-x model), the counter-ring is suppressed while forming, and the native-answer consumer won't tear down our forming call. Root + design from the internal research workflow. Not yet validated on device.
Re-dial after a crossed/cancelled DM call now rings again: DM 'ongoing' is peer-scoped so a stale own membership no longer forces a join_existing intent (which drops the ring), and an outgoing start waits for our own membership to leave; zombie same-room dispose first gives the widget a bounded chance to send its leave. Plus: incoming-ring suppress ignores stale own-device membership, useCallJoined resets per embed, no-answer timer re-anchors to the ring actually sent, mute mirror tracks last-sent state, SW self-dismiss checks eventId, Telecom disconnect clears a dead-widget atom, and a same-room join marks the native session answered. From the internal multi-agent review.
