[research][transport] Define browser-native WebRTC provider reachability

[RobLe3]

Goal

Research browser-native provider reachability through WebRTC DataChannels as an optional path when a browser cannot create a native tunnel.

Historical context: RobLe3/iicp.network#523.

Required design

• STUN-assisted direct connectivity with explicit signaling boundaries;
• TURN or existing relay fallback for symmetric NAT and restricted networks;
• encrypted IICP task framing over the DataChannel;
• signaling metadata retention, abuse and privacy analysis;
• browser compatibility and failure-mode evidence.

A browser cannot spawn cloudflared or bind a raw listening port. Directory signaling, if used, remains control-plane metadata and must not carry task payloads. This issue does not make WebRTC or TURN a required IICP transport.

[RobLe3]

Edge-Net/QuDAG prior art was reviewed without treating README claims as implementation proof: IICP boundary assessment.

Edge-Net's signaling server provides useful message-level separation between capability discovery and WebRTC offer/answer/ICE forwarding. However, the inspected pkg/p2p.js imports a missing pkg/webrtc.js, so it is not portable end-to-end evidence or code to lift. Use only the general test cases: transient connection IDs must not replace persistent provider identity; candidates need expiry/provenance; stale signaling membership must fail closed; relay fallback must not imply task authorization.