Fix WASM build: extract platform-specific WebRTC API creation

[myleshorton]

Summary

• SettingEngine.SetNet() in pion/webrtc v4 is gated by //go:build !js, so calling it in consumer.go breaks WASM compilation
• Extracts WebRTC API creation into build-tagged helpers: webrtc_api.go (native, with SetNet/stdnet) and webrtc_api_js.go (WASM, plain webrtc.NewAPI())
• Removes dead commented-out DTLS example code from consumer.go

Test plan

• go build ./... passes (native)
• GOOS=js GOARCH=wasm go build ./cmd/ passes
• Verify widget still connects via WebRTC in browser

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR fixes WASM compilation by extracting platform-specific WebRTC API creation logic into build-tagged helper functions. The issue arose because SettingEngine.SetNet() in pion/webrtc v4 is unavailable in JavaScript/WASM builds (gated by //go:build !js), causing compilation failures when called directly in consumer.go.

Changes:

• Created webrtc_api.go for native builds with SetNet() and stdnet support
• Created webrtc_api_js.go for WASM builds with plain webrtc.NewAPI()
• Updated consumer.go to use the new newWebRTCAPI() helper and removed dead commented code

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
clientcore/webrtc_api.go	Native build implementation with SettingEngine and SetNet support
clientcore/webrtc_api_js.go	WASM build implementation using plain webrtc.NewAPI()
clientcore/consumer.go	Refactored to use newWebRTCAPI helper, removed stdnet import and dead DTLS example code

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The build tag //go:build js && wasm is more restrictive than the pattern used elsewhere in the codebase. Other WASM-specific files like ui_wasm_impl.go and client_wasm_impl.go use just //go:build wasm. For consistency with the existing codebase, consider using //go:build wasm instead of //go:build js && wasm. While js && wasm is more specific and technically correct for JavaScript-targeting WASM builds, consistency with existing patterns would be preferable unless there's a specific reason for this difference.

Suggested change

	//go:build js && wasm
	//go:build wasm

[Copilot]

For consistency with other build-tagged files in the codebase (like ui_default_impl.go which uses //go:build !wasm and ui_wasm_impl.go which uses //go:build wasm), consider using //go:build !wasm instead of //go:build !js. This would maintain consistency with the established pattern in the codebase.

Suggested change

	//go:build !js
	//go:build !wasm

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.