When `muteOnStart=true`, the initial local mute state in AudioManager is
desynced from the server. This issue stems from two recent changes:
- Decoupling voice activity updates from the main user_voice subscription,
which introduced an implicit muted state placeholder value
of true instead of false. See user_voice_activity's DB schema
propagation rules.
- Introduction of dialplan-level muteOnStart, muting channels on creation
rather than after.
Without properly updating AudioManager's `isMuted` placeholder, no
user_voice_activity update triggers *when joining audio* with
muteOnStart=true, causing two issues:
- Sender tracks are not locally muted on audio join.
- Opening the audio settings modal while muted will cause the
microphone to be incorrectly *unmuted* once it's closed (first try only).
This fix sets AudioManager's `isMuted` placeholder to true, matching the
server. Additionally:
- Enforce the local mute state before joining audio to ensure the desired
sender track state. Should make this a bit more future proof.
- Track `user_voice_activity` before joining audio (rather than after)
to avoid race conditions.
- Clean up `AudioManager.init` (loadBridges no longer returns a promise etc).
47018e5a65