UX: Enable WebRTC calls and background audio in the iOS webview

[Grubba27]

What

Configuration to let WebRTC/LiveKit-based plugins (e.g. resenha) run voice and video calls inside the iOS in-app webview, and keep call/media audio playing when the app is backgrounded or the screen is locked.

ios/Discourse/Info.plist

• Add audio to UIBackgroundModes — webview audio (including WebRTC remote audio) keeps playing in the background, and Picture-in-Picture video can continue outside the app.
• Mention voice/video calls in the microphone/camera usage descriptions — App Review checks that these strings match actual usage, and the old ones only covered composer uploads.

js/screens/WebViewScreenComponents/WebViewComponent.js

• mediaPlaybackRequiresUserAction={false} — remote WebRTC audio can start without a fresh user gesture (needed for joins, reconnects, and new participants attaching audio tracks). Side effect: embeds that explicitly request autoplay-with-sound are no longer blocked.
• mediaCapturePermissionGrantType="grantIfSameHostElsePrompt" — stops WKWebView re-showing its own "Allow site to use your microphone?" dialog every session for the site itself. The one-time OS-level permission prompts are unaffected, and embedded third-party origins still prompt.
• Explicit allowsPictureInPictureMediaPlayback / allowsAirPlayForMediaPlayback.

Android needs no changes: sites open in Chrome Custom Tabs, where calls, permissions, background audio, and media notifications already behave like regular Chrome.

Known platform limits (not addressable by configuration)

• Mic in background: WKWebView force-mutes getUserMedia capture shortly after the app backgrounds — WebKit bug 233419, open since 2021 and still reproducing on iOS 18.3 (Apple forums). Backgrounded users keep hearing the call but go mic-silent until they return. The fix is a native LiveKit bridge — see the livekit-native-bridge branch.
• Screen share initiation: getDisplayMedia is unavailable in all mobile browsers/webviews. Viewing someone else's screen share works (it is just an incoming video track); starting one from a phone requires native ReplayKit/MediaProjection work.

How to test

On a physical device (simulators have no camera and unreliable WebRTC):

1. Open a site running a WebRTC-based plugin (resenha) in the app, join a voice/video room.
2. Expect one OS mic/camera prompt, no repeated per-session webview prompts.
3. Background the app or lock the screen → room audio keeps playing.
4. Return to the app → mic capture resumes.
5. Sanity-check that regular topics with uploaded videos/oneboxes don't unexpectedly autoplay with sound.