webrtc: run the real polymorph conformance suite (driver-ct solo+pair) under deltic

[lann]

ports/webrtc's component gate was the echo-demo (green over real data channels), but polymorph-webrtc-datachannels' actual conformance suite — the driver-ct solo+pair matrix with conformance-signalingd and the interop directions — has not been attempted under deltic. That suite is the migration gate for that repo. Needs: the signaling mailbox served (their jco leg does it via fetch — deltic leg can too), suite bounds wiring, and a triage pass mirroring ports/websocket/conformance/run.ts. Blocks the webrtc row of #14.

[lann]

Scope clarification (operator ruling on #21): this issue covers running their conformance suite's loopback targets under a deltic leg (the analogue of their jco-node target — solo+pair over the signaling mailbox, all same-host). NAT/Shadow/netns rows are explicitly NOT deltic's to run or build — they live in polymorph-webrtc-datachannels' own CI and pick up the deltic leg via upstreaming (#14).

[lann]

Reframed (operator ruling, also recorded in docs/consumers.md): consumer suites are engine sanity checks, not gates — everything is unstable and co-evolves in tandem. This issue does not block the webrtc row of #14; it stays open because running their real driver-ct solo+pair matrix under deltic is high-yield defect discovery (cf. the tls smoke, #18, which found three runtime defects), not because upstreaming waits on it.

[lann]

Done — merged as polymorph-webrtc-datachannels#149 (side-by-side per the websocket/tls pattern; loopback scope per the ruling above, NAT/Shadow/netns untouched).

The real driver-ct solo+pair matrix runs under deltic as a standing fifth loopback target deltic-deno: rtc-ct-driver gained a Deno peer kind spawning conformance/driver-ct/deltic/run.ts (the jco child contract exactly — RTC_CT_* env, --select, JSONL on stdout, 512 KiB bound), against the upstreamed host module (deltic-impl/, from ports/webrtc) and a fetch mailbox port. Signaling mailbox, suite bounds, and the fold all ride their existing orchestrator. 37/37 (25 solo + 12 pair folded) — green on the dev box AND on their ubuntu runner, matrix rows identical to wasmtime/composed/jco case for case. Pin pre-10cc776.

The high-yield-defect-discovery bet paid out threefold:

1. solo/post-close-send (flaky) → the pc.close() wrapper-latch defect in ports/webrtc (ports/webrtc: latch owned channels on peer-connection close #36; jco-impl carries the same latent race, noted in their PR).
2. Their runner CI exposed the unit-test candidate-buffering race behind ports/webrtc loopback tests: no ICE connectivity on GH Actions runners #21 (ports/webrtc tests: buffer trickled candidates; settle after addon cleanup (#21 root cause) #37) — a defect in OUR test helper, not their environment.
3. The addon-teardown SIGSEGV under deno test's exit window (ports/webrtc tests: buffer trickled candidates; settle after addon cleanup (#21 root cause) #37).

Suite-level: zero deltic runtime defects — scheduler, streams, callback-ABI async all clean under a real WebRTC workload.