fix(call): guard against a missing local state broadcaster when leaving a call

[bakiburakogun]

Fixes an uncaught TypeError: Cannot read properties of null (reading 'destroy') raised by the beforeLeaveCall handler in src/utils/webrtc/webrtc.js.

localStateBroadcaster is created in the beforeJoinCall handler and set back to null at the end of beforeLeaveCall, but the leave handler dereferences it without checking. It is null in at least two situations: when the call was never joined in this page session, and when the leave path runs a second time. leaveRoom() calls leaveCurrentCall() unconditionally, so simply leaving or switching a conversation reaches the handler either way.

The exception is raised inside the promise chain of leaveCall(), so it aborts whatever the caller was doing. We ran into it while investigating #19081, where adding a participant to a one-to-one conversation during a call moves everyone to the new group conversation but the call does not continue there. The stack from that reproduction:

webrtc.js:528 Uncaught (in promise) TypeError: Cannot read properties of null (reading 'destroy')
    at Function.<anonymous> (webrtc.js:528:25)
    at PN._trigger (signaling.js:115:12)
    at Base.leaveCall (signaling.js:334:9)
    at Base.leaveCurrentCall (signaling.js:213:9)
    at Base.leaveRoom (signaling.js:251:7)
    at leaveConversation (participantsStore.js:1141)
    ...
    at signaling.js:1439        <- case 'switchto'

The change only adds the missing null check. When the broadcaster exists the behaviour is unchanged.

I have not verified that this alone makes the call continue in #19081, so I am not closing that issue with this pull request. The exception is wrong on its own and swallowing it is not the goal, guarding the dereference is.

Environment where this was observed: Nextcloud 34.0.3, Talk 24.0.4, external signaling server v2.1.1.

[bakiburakogun]

Tested in production. I applied the equivalent change to the shipped bundle on our instance (Nextcloud 34.0.3, Talk 24.0.4, external signaling v2.1.1, four signaling servers) and reran the scenario from #19081.

With the null check in place the call now continues after a one-to-one conversation is extended into a group conversation: the two sessions leave the old room, join the new one, and the call is re-established one second later. The participant who was just added joins the call as well. Details and the signaling timeline are in #19081 (comment)

The TypeError is gone from the console and no new errors appeared in that flow.

So this change is not only a defensive guard, it also resolves that issue in our tests. I left the issue open rather than marking it fixed here, in case you consider the underlying ordering worth a closer look.