Audio lost (both directions) when app is backgrounded during an ongoing Element Call

### Steps to reproduce

1. Start an Element Call between two users (Element X iOS calling another Matrix client). Audio works normally while the iOS app is in the foreground.

2. While the call is ongoing, press the Home button or swipe to another app - Element X is backgrounded (NOT killed). All background permissions are enabled (Background App Refresh, Audio, VoIP notifications).

3. After a short moment (1-3 seconds), audio is lost in BOTH directions: the iOS user cannot hear the other participant, and the other participant cannot hear the iOS user.

4. Bringing Element X back to the foreground does not always restore audio - often the call must be rejoined.

Note: This happens with a self-hosted Synapse + LiveKit SFU + Coturn TURN stack. All server endpoints have been verified correct (LiveKit health OK, lk-jwt issuing tokens, .well-known/matrix/client advertising rtc_foci, TURN server reachable). Web research points to element-call element-hq/element-x-ios#3865 (WKWebView AVAudioSession suspended by iOS when backgrounded) and element-x-ios element-hq/element-x-ios#1443/#3136/#4356.

### Outcome

#### What did you expect?
Audio should continue in both directions when the app is backgrounded, as iOS provides VoIP background audio support for apps with an active AVAudioSession and the appropriate background mode entitlements.

#### What happened instead?
Audio is completely lost in both directions within seconds of backgrounding. The WKWebView's AVAudioSession appears to be suspended by iOS when the app transitions to the background state.

#### Additional context
Server-side investigation confirms all server configs are correct (Synapse, LiveKit, Coturn, lk-jwt, .well-known). However, we found that LiveKit's UDP media port range (50000-50200) accidentally collides with Coturn's published port range on the same host, forcing the SFU to fall back to TCP-only media (port 7881). While this is OUR server-side config mistake (not an Element X bug), it means media rides TCP instead of UDP. iOS is known to be more aggressive about suspending background TCP connections, which may amplify the AVAudioSession suspension issue.

### Your phone model

Iphone 12 & 13 mini

### Operating system version

IOS 26.latest

### Application version

latest

### Homeserver

(self-hosted Synapse)

### Will you send logs?

No

The report identifies backgrounding an Element X iOS call and points to element-call#3865 plus element-x-ios#1443, #3136, and #4356; no element-call file or test is named. Start by tracing the app's background and AVAudioSession handling while reproducing with logs, separating the reported Coturn/LiveKit port collision from the client symptom. Done means bidirectional audio remains after backgrounding and reliably returns on foregrounding.

Written by the indexing model from the issue text.