Switch webrtc from multiprocessing to threading

[yeldarby]

What does this PR do?

The local WebRTC worker (/initialise_webrtc_worker) was crashing with SIGSEGV on macOS because multiprocessing.get_context("spawn") forces a child process to re-import and re-initialize all C extensions (PyTorch, av, aiortc), which segfaults in native code.

Fix: Replace the multiprocessing subprocess with a threading.Thread running its own asyncio.new_event_loop() for the local (non-Modal) code path. The SDP answer is communicated back via asyncio.Future + call_soon_threadsafe. This avoids subprocess spawn entirely, eliminating the segfault. The Modal (production) path is unchanged.

Also added defensive error handling in cpu.py so that if the multiprocessing path is ever used, unhandled exceptions are logged and sent back through the pipe instead of silently killing the child process.

Type of Change

• Bug fix (non-breaking change that fixes an issue)

Testing

• I have tested this change locally

Test details:

• Verified /initialise_webrtc_worker no longer crashes with SIGSEGV on macOS
• Confirmed WebRTC peer connection establishes successfully via the threaded worker

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• My changes generate no new warnings or errors

[grzegorz-roboflow]

I'd vote for adding 3rd option to run workers - we can have 3 options coexisting and turned on based on user requirements