sctp: discard pre-established DATA so webdartc↔webdartc data channels open

[nus]

Fixes a real functional gap found during the bufferedAmount work: a data channel opened webdartc↔webdartc never reached open — the opener's onOpen never fired and readyState stayed connecting. (All existing DC e2e tests use a browser, so this went unnoticed.)

Root cause — a DCEP ACK lost to an SCTP establishment race

1. The server peer establishes on COOKIE-ECHO and immediately sends the DCEP DATA_CHANNEL_OPEN, which overtakes the COOKIE-ACK and reaches the client still in COOKIE-ECHOED.
2. _handleData processed that DATA regardless of state and fired onDataChannelOpen, but the DCEP ACK reply failed sendData's established guard and was silently dropped — yet the OPEN was still SACKed, so the sender never retransmitted. Permanent stall.

How libwebrtc/pion avoid this: pion's handleData returns early when state != established (RFC 4960 §5.1) — it discards the DATA without SACKing, so the sender's T3-rtx retransmits it after the receiver establishes.

Fix

• _handleData (state_machine.dart) discards DATA received before established and does not SACK it — matching RFC 4960 §5.1 / pion. Correctness is now independent of chunk ordering (the peer's T3-rtx recovers).
• Ordering optimization (peer_connection.dart): the DCEP OPEN send is deferred to a scheduleMicrotask so the COOKIE-ACK is flushed to the wire first — avoids the ~3s retransmit wait in the common case.

The two are layered deliberately: the guard is the load-bearing correctness fix; the microtask is a latency nicety.

Tests

• New webdartc↔webdartc loopback test (data_channel_open_test.dart): both peers fire onOpen/ondatachannel and a message round-trips — completes in <1s.
• dart analyze clean; 665 unit + 22 e2e (Chrome/Firefox) pass; closes the BACKLOG item. A latent follow-up (gate _handleSack/_handleHeartbeat/_handleReconfig pre-established, pion parity) is recorded in BACKLOG.

Reviewed with /simplify.

🤖 Generated with Claude Code