Enable WARP (SPED + SNAP), gated by the server

[pblazej]

Enables WARP (draft-uberti-tsvwg-warp). This is the best of #1128 (@cloudwebrtc) and #1094 (@hiroshihorie) merged into one PR, and it supersedes both.

• SPED (DTLS in STUN): the WebRTC-IceHandshakeDtls field trial, passed to LKRTCPeerConnectionFactory.configureFieldTrials right before the factory is built. This avoids the deprecated LKRTCInitFieldTrialDictionary.
• SNAP (SCTP INIT in SDP): enableSctpSnap = true in LKRTCConfiguration.liveKitDefault(). Every configuration, including the setConfiguration calls on quick reconnect and early-publisher adoption, is built from it. So this immutable field never changes after the peer connection exists, which was the INVALID_MODIFICATION trap in Add WARP support (DTLS handshake carried in the ICE exchange) #1128.

WARP is always on, with no public API and no runtime switch, the same as rust-sdks#1342. The server decides whether WARP engages. A server without WARP ignores the offer and the connection falls back to the standard handshake.

SPED was turned off in #1015 on suspicion of #929. That crash turned out to be the ADM fine_audio_buffer_ null dereference, fixed in #1041.

Testing

WARPTests checks that the offer carries both goog-sped-v1 and a=sctp-init:. Removing either leg makes it fail (verified).

End to end, against local livekit-server 1.13.7 (the latest release; it ships the livekit/ice v4.4.0-warp.2 / dtls v3.1.5-warp.1 / webrtc-pion v4.2.18-warp.1 forks). The test connects two rooms and sends one reliable packet:

	rtc.enable_warp: true	WARP off
SPED	completes on both active transports: libwebrtc logs DTLS-STUN piggyback complete with success=1, the SFU logs Done with the SPED handshake	not engaged
SNAP	a=sctp-init in all four SDPs (client offer, SFU answer, SFU offer, client answer)	only in the client offer; the SFU drops it
data round trip	✅	✅

To reproduce, add this to the server config: rtc: { enable_warp: true } and logging: { pion_level: debug }.

Server-side fixes

WARP needs a server with livekit/livekit#4916 (on master, not yet in a release). Against livekit-server 1.13.7, SPED causes two problems. Neither is a client bug, and both are fixed in LiveKit's pion forks:

• Keep the in-flight read when an injected packet wins nextPacket dtls#1: after a SPED handshake, the SFU silently dropped the client's first SCTP packets. That covers data-channel OPENs, DATA, SACKs and their retransmissions, and it lasted for seconds.
• Hold DTLS flights produced after SPED fallback until ICE connects ice#4: clients without SPED paid ~100 ms extra per connect against a WARP-enabled server. This affects older SDKs.

Measured locally on loopback with this PR's client. For the data rows, a fresh pair of rooms is used per iteration, with n=10 for first messages and n=5 for bursts.

	1.13.7	master (#4916)
First reliable message after connect (dual PC)	9/10 took 3.4–12.4 s	12–14 ms
First reliable message after connect (single PC)	~0.4 s	11–13 ms
100 lossy messages right after connect	0–96 delivered	100/100
100 reliable messages right after connect	100/100	100/100
SFU SCTP retransmit timeouts	21	0

The connect-time rows are BM-CONN: dual PC, n=25, p50 / p90.

Client	1.13.7, WARP on	master, WARP on	Server without WARP
with WARP (this PR)	34 / 40 ms	18 / 38 ms	53 / 81 ms
without WARP	127 / 132 ms	45 / 76 ms	43 / 63 ms

CI's dev server doesn't enable WARP, so CI doesn't exercise either path.

[devin-ai-integration]

Devin Review found 1 potential issue.

[pblazej]

Stability fixes should come after #1131