fix(cloudxr): start runtime with spawn context

[WilliamK112]

Summary

• start the native CloudXR runtime process from a spawn multiprocessing context instead of the platform-default fork context
• keep the existing multiprocessing.Process handle shape so readiness polling and terminate_or_kill_runtime cleanup continue to work unchanged
• add a focused unit test that stubs the native CloudXR imports and verifies the spawn context is requested

Rationale

Issue #40 calls out that the current multiprocessing.Process(target=runtime_run) path can fork from inside an already-running asyncio launcher. Using spawn starts the runtime in a fresh interpreter, avoiding inherited asyncio lock/signal-handler state, while keeping this patch small and avoiding a broader subprocess-handle refactor.

Fixes #40

Validation

• Rebased onto current NVIDIA/xr-ai@ec4169aa3e3c8a57f1d7f59d3e2d97ad9163a8bb
• uv run pytest -v test_cloudxr_runtime_process.py (from tests/) - 1 passed
• uv run pytest -v test_cloudxr_runtime_process.py test_launcher_cloudxr_env.py (from tests/) - 24 passed
• uv run python -m py_compile ..\cloudxr-runtime\cloudxr_runtime\__main__.py test_cloudxr_runtime_process.py (from tests/)
• uv tool run --from ruff==0.15.16 ruff check cloudxr-runtime\cloudxr_runtime\__main__.py tests\test_cloudxr_runtime_process.py
• git diff --check origin/main..HEAD