Part of #280 / breakdown of #637. AC #2 requires the mute state be reflected across ALL call participants, but the existing EndpointMessage remote-mute only instructs the single target to mute itself and does not broadcast state to other participants' UIs.
Decide and implement one of:
- (a) Broadcast mute-state change over the data channel to all endpoints so each client updates its participant-list UI, or
- (b) Persist per-participant admin-mute state in the backend (intercom-manager) and surface it via the existing ~5s participant-list poll / WebSocket state push.
Also decide the enforcement model: advisory (target client honors the directive but could locally re-enable its track) vs authoritative/server-enforced (target cannot self-unmute while admin-muted — closer to broadcast forced-mute/priority norms).
Acceptance:
- A global mute/unmute performed by an admin is visible in every participant's admin panel/participant list within the normal state-refresh interval.
- Enforcement behavior matches the agreed model and is documented.
Broken down from #637 by daily-backlog-pr triage (intercom-expert verdict).
Part of #280 / breakdown of #637. AC #2 requires the mute state be reflected across ALL call participants, but the existing EndpointMessage remote-mute only instructs the single target to mute itself and does not broadcast state to other participants' UIs.
Decide and implement one of:
Also decide the enforcement model: advisory (target client honors the directive but could locally re-enable its track) vs authoritative/server-enforced (target cannot self-unmute while admin-muted — closer to broadcast forced-mute/priority norms).
Acceptance:
Broken down from #637 by daily-backlog-pr triage (intercom-expert verdict).