webrtc: Warning logs spammed for every connection

Reproduction path with:

• https://github.com/lexnv/litep2p-perf/pull/4

2026-05-25T10:42:30.319671Z  INFO litep2p_perf: Event: ConnectionEstablished { peer: PeerId("12D3KooWK5cpS16bj7VQQXzS5xWYyGhUvt6mKSqm7tvL39WPYYQe"), endpoint: Listener { address: /ip4/127.0.0.1/udp/48086/webrtc-direct/certhash/uEiCVH9ycEm6Nl-l04x3WfPLmcyWfIDqscnuQzVYQbQLe3w/p2p/12D3KooWK5cpS16bj7VQQXzS5xWYyGhUvt6mKSqm7tvL39WPYYQe, connection_id: ConnectionId(0) } }
2026-05-25T10:42:30.319936Z  WARN str0m: Drop BufferedAmountLow for id: 0
2026-05-25T10:42:30.322256Z  WARN str0m: Drop ChannelData event for id: 2
2026-05-25T10:42:30.322269Z  WARN str0m: Drop ChannelData event for id: 2

Each connected client will spam at least 3 warnings coming from str0m.
Ideally, we should cleanup the logs before stabilizing webrtc.

For each warning WARN str0m: Drop BufferedAmountLow for id: 0 and WARN str0m: Drop ChannelData event for id: 2:

• investigate what is the root cause of the warnings (ie are we misusing the API?)
• either fix them on the litep2p side or downgrade them upstream

cc @gab8i @skunert @dmitry-markin

Start with the reproduction path in litep2p-perf pull request 4 and inspect the WebRTC handling associated with the BufferedAmountLow and ChannelData warnings from str0m. Determine whether litep2p is misusing the API or whether the warnings should be downgraded upstream. Done means the warning spam is eliminated or appropriately reduced for each connection.