fix(webrtc-websys): defer data channel callback wakes - #6558

Description

Fix a lifetime and re-entrancy bug in the WebRTC WebSys data-channel callbacks.

PollDataChannel previously allowed a queued browser event to invoke a wasm-bindgen closure after its Rust owner had been dropped. Waking the task synchronously from the callback could also re-enter polling while wasm-bindgen still held a mutable borrow of that closure. Either path could panic with closure invoked recursively or after being dropped.

Keep the RTCDataChannel and its registered closures in a shared owner, remove the handlers before the final owner is released, and defer waker notifications until after the JavaScript callback returns.

Fixes #6551.

AI Assistance Disclosure

Tools used (required — write none if no AI was used): Codex (GPT-5)

Attestation (required):

• I have read every line of this diff, understand what it does, and can explain it in review.

Notes & open questions

Validation performed:

• cargo fmt --check -p libp2p-webrtc-websys
• cargo check -p libp2p-webrtc-websys --target wasm32-unknown-unknown
• Browser-to-browser WebRTC relay transfer testing: the wasm-bindgen callback exception no longer occurs and file transfer completes.

The 8 KiB framing behavior encountered during the same investigation is intentionally out of scope and is tracked in #6557.

No standalone automated regression test was added because reproducing the stale browser-event timing requires an actual browser WebRTC runtime. No user-facing documentation change is needed. I have not added a changelog entry for this internal correctness fix; happy to add one if maintainers prefer it.

Change checklist

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• A changelog entry has been made in the appropriate crates