ports/webrtc loopback tests: no ICE connectivity on GH Actions runners

[lann]

First CI run (31316958096): all 8 connection-forming loopback tests time out (WitError: timed-out at wait-connected) on BOTH ubuntu-24.04 and ubuntu-24.04-arm, while the addon loads fine and the non-connection test passes. Same tests are green on the dev box, where a real LAN interface supplies host candidates that route locally. Runners' network namespaces evidently don't give libdatachannel a same-host ICE path — the failure mode the polymorph wasmtime host's WEBRTC_INCLUDE_LOOPBACK knob exists for.

Candidate fixes: (a) get loopback candidates included under node-datachannel (libdatachannel supports it; the polyfill may need a config passthrough), (b) bindAddress pinning, (c) the werift backend on CI (pure TS — currently documented-unverified in the port), (d) a local TURN/STUN helper on the runner.

Until then the CI step is continue-on-error (ci.yml comment references this issue); the dev-box run stays the real gate. Relates to #19 (the full conformance suite run will hit the same wall on runners).

[lann]

Diagnosis correction after studying polymorph-webrtc-datachannels' CI (their Conformance workflow is green on stock ubuntu-latest, most recently 2026-08-07, running the full jco-node and jco-browser loopback targets):

1. libdatachannel pairs same-host on GH runners out of the box. Their matrix job has zero network setup — checkout, Node 24, npm installs, run. Default polyfill config (iceServers: [], the polyfill's own default), no knobs. Their harness even documents the corpus as "loopback-I/O-bound".
2. WEBRTC_INCLUDE_LOOPBACK is a webrtc-rs-only knob (their wasmtime-demo binaries): webrtc-rs prunes loopback candidates by default; libdatachannel does not need the toggle. My original "runners give libdatachannel no ICE path" claim is contradicted by their green CI on the same runner image with the same addon version (0.32.3) and same default config.
3. For genuinely non-loopback coverage they deliberately avoid fighting runner networking: the pair corpus runs inside the Shadow discrete-event simulator (routed paths, deterministic, no root), and the STUN/TURN/NAT netns lab is explicitly workstation-only.

So the failure here is NOT environmental impossibility. Remaining delta space: Deno-vs-Node on the runner (their legs run Node 24; ours Deno — though the dev box runs these tests green under Deno, so it would have to be a Deno×runner interaction, e.g. addon event/timer integration under node-compat on a 2-core runner), the port's code paths, or the tests' wiring/timeouts.

Next step is empirical, not speculative: a manual-dispatch debug workflow running one loopback test with initLogger("Debug") + per-candidate/per-state logging, plus a control leg running the equivalent probe under Node on the same runner to bisect runtime-vs-environment.

Also noteworthy for #19: their Shadow executor is the pattern to reuse for our non-loopback pair coverage rather than inventing one.

[lann]

Scope ruling (operator): NAT-behavior coverage is OUT of scope for this repo — it belongs to polymorph-webrtc-datachannels' conformance system (their driver's Shadow/netns rows), where deltic is just another execution leg once upstreamed (#14). Retracting the previous comment's suggestion to reuse the Shadow executor here. This issue's scope is narrowly: make our own CI able to run ports/webrtc's LOOPBACK unit tests (or prove it's a Deno-on-runner interaction and document the dev-box gate as authoritative). Nothing topology-shaped gets built in deltic.

[lann]

Root-caused and fixed — it was never runner networking. Empirical record (probe matrix on ubuntu-latest, polymorph-webrtc-datachannels scratch run 31349796767, driven from their #149):

• All runtime × layer × bind combos (node/deno × raw-addon/polyfill × default/127.0.0.1-bind) pair on the runner in ~1 s. libdatachannel needs no loopback knob there; the polyfill needs no config passthrough.
• The unit-test timeouts were a race in the tests' own connectPair: candidate pumps started before the offer/answer exchange, and addIceCandidate rejections were swallowed. On the runner the host candidates arrive ~12 ms in — before the counterpart's remote description — so every candidate was rejected (invalid-signaling) and lost, and wait-connected timed out. The dev box merely won the race; a raw-API probe with the same ordering fails under Node identically (runtime-independent). The header comment even claimed the buffering discipline from the original webrtc-deno probe — the code lost it in the probe→test port.
• Residual: with the race fixed, deno test still died SIGSEGV after all tests passed — the exit raced libdatachannel's thread joins during the post-cleanup() teardown window (a hard exit right after cleanup() is clean, which is why standalone probes never showed it). Fixed with a settle in the cleanup test.

Fixes merged: #37 (buffered pumps + settle; also mirrored into the consumer's upstreamed copy in their #149) and #36 (the related pc.close() wrapper-latch defect their conformance suite exposed). #38 flips test-webrtc to a required core step, discharging this issue's scope.