Embed CloudXRLauncher lifecycle inside TeleopSession

Embed CloudXRLauncher lifecycle inside TeleopSession

Context

In the live teleop path, users currently have to set up the CloudXR runtime
launcher and the teleop session as two separate context managers:

​```python
with launcher_ctx as launcher:
if launcher is not None:
print(f"[live] CloudXR runtime started (WSS log: {launcher.wss_log_path})")
print("[live] waiting for headset connection… (Ctrl+C to stop)")

with TeleopSession(config) as session:
    ...

​```

This was raised in review on the mcap-example PR (@aristarkhovNV): the nested
launcher context is extra plumbing the caller shouldn't have to wire up by hand.
Deferring it out of that PR to keep its scope on the mcap example only.

Proposal

Have TeleopSession optionally own the CloudXRLauncher lifecycle so the
common case collapses to a single context manager:

​python with TeleopSession(config) as session: ... ​

TeleopSession.__enter__ would start the launcher (when configured for the
live/CloudXR path) and __exit__ would tear it down, surfacing wss_log_path
and any launcher state via the session object.

Motivation

• Removes boilerplate and the nested with from every caller.
• Single ownership point for startup/teardown ordering (launcher must come up
  before the session connects, and tear down after).
• Centralizes the launcher is not None guard instead of leaking it to callers.

Open questions / considerations

• Opt-out path: keep the ability to inject an externally-managed launcher
  (e.g. pass launcher=... or manage_launcher=False) for callers that need to
  share one launcher across sessions or control its lifecycle themselves.
• Backward compatibility: does anything depend on the current two-context
  shape? If so, keep the standalone launcher context working.
• Failure semantics: if the launcher starts but the session fails to
  connect, ensure the launcher is cleanly torn down (no orphaned runtime).
• Logging: preserve the [live] CloudXR runtime started (WSS log: …) and
  "waiting for headset connection" messages, moved inside the session.

Acceptance criteria

• TeleopSession can start/stop the CloudXR launcher internally when configured.
• Single with TeleopSession(config) works for the live path.
• An escape hatch exists for an externally-managed launcher.
• Startup/teardown ordering and failure cleanup are covered by a test.
• Existing mcap example still works.

Start with the TeleopSession and CloudXRLauncher entry points and inspect the existing mcap example's nested context managers. Trace startup, connection failure, and teardown ordering, then add coverage showing internal ownership, external-launcher opt-out, and clean failure cleanup; the existing mcap example must still work.