WebRTC relay path can reject the default 16 KiB framed message size

Thank you for maintaining the WebRTC transport.

We observed that the default 16 KiB WebRTC framing limit can exceed the effective SCTP/DataChannel message limit on a real browser -> webrtc-direct relay -> browser path.

Observed behavior

Connection establishment and control traffic succeed. Once transfer data starts, the relay reports:

outbound packet larger than maximum message size

The peers then observe:

connection is closed
unexpected end of file

For local validation, reducing libp2p_webrtc_utils::stream::MAX_MSG_LEN from 16 KiB to 8 KiB allowed the same browser-to-browser transfer to complete repeatedly.

Why I am opening an issue before a PR

The 16 KiB value follows the RFC 8831 guidance for non-interleaved messages. I do not think changing the global default to 8 KiB is necessarily the right fix: it could unnecessarily reduce throughput for native WebRTC users.

Could you advise on the preferred design direction?

1. Derive the framing limit from the effective SCTP/WebRTC maxMessageSize, where available.
2. Expose the maximum WebRTC frame/message size as transport configuration.
3. Use a conservative default only for webrtc-websys or relay paths.
4. Proactively fragment before the underlying SCTP/DataChannel layer rejects an oversized message.

I can provide full relay logs, browser console logs, and a minimal reproduction if useful. I would be happy to prepare a PR once there is agreement on the desired API and behavior.

Start with libp2p_webrtc_utils::stream::MAX_MSG_LEN and reproduce the browser -> webrtc-direct relay -> browser transfer described in the issue. Compare the effective SCTP/DataChannel message limit with the 16 KiB framing limit and review the four proposed design directions. Done means an agreed API and behavior that lets the transfer complete without unnecessarily reducing native WebRTC throughput.