620039a2ff
Rebuild the iOS remote-support screen share the RIGHT way: keep the exact Share/Connect UX + session (consent + symmetric session-ended), swap only the media to LiveKit since WKWebView can't getDisplayMedia. (Replaces the earlier "route to a meeting" detour, which was reverted.) Flow: customer taps Share Screen -> gets a 6-digit code (unchanged UI) -> helper enters it in Connect Screen -> on the customer's "Allow", the app publishes the screen natively (ReplayKit -> LiveKit) into a per-session room and tells the agent it's a LiveKit session -> connect.html joins that room and shows the screen in its existing viewer (recording/controls intact). Chat runs over the session socket (no P2P data channel in this mode). Either side ending fires the existing session-ended -> both tear down (symmetric disconnect). - signaling.js: relay 'rs-livekit' + 'rs-chat' between the two ends. - home.html: parent bridge so the /share iframe can drive startMeetingScreenShare/ stop on the native plugin (+ a capability handshake). - share.html (iOS): publish via native LiveKit instead of getDisplayMedia; chat over WS; hide mic (voice = next iteration) + remote-control (impossible on iOS). - connect.html: LiveKit viewer for iOS-shared sessions, reusing the P2P viewer. Web-only, no new build (reuses the shipped startMeetingScreenShare). Desktop Share/Connect P2P unchanged. Two-way voice is the planned follow-up. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>