"No hardware" examples still need a running OpenXR runtime, and no page says to start one

Found during internal QA of the 1.4 release.

Several examples are documented as running without hardware, but they still open an OpenXR session, and that needs a runtime running — a separate thing from having a headset attached. With no runtime up, xrCreateInstance returns -51 (XR_ERROR_RUNTIME_UNAVAILABLE) and the example dies before it does anything. None of the affected pages carry a step that starts one.

Affected as reported

• The schemaio pedal pair (pedal_pusher / pedal_printer) — docs/source/device/add_device.rst L193 gives the cmake build and the run commands with no runtime step in between.
• The synthetic joint-space leader plugins — docs/source/device/joint_space.rst L89 and L118, both labelled # Synthetic backend (no hardware).

The joint-space page is the sharper case: on that same page the probe modes and the MCAP replay path are explicitly annotated "no OpenXR runtime needed". Against that wording, an unqualified "no hardware" reads as "no runtime either", which is precisely the wrong inference.

One correction to the original QA note

NV_CXR_RUNTIME_DIR is not normally something a user has to set. src/core/oxr/cpp/oxr_session.cpp L66-67 defaults it to ~/.cloudxr/run, which matches the standard install layout; it only needs overriding when the runtime lives elsewhere, as in the NGC runtime image where it is /openxr/run. So the gap to close is the "start a runtime first" step, plus a note on when the run directory has to be pointed somewhere else — not an undocumented mandatory environment variable.

Suggested fix

We should hooked up all the examples with CloudXRLauncher (via Python), or better: make a Rig (https://nvidia.github.io/IsaacTeleop/main/references/rig.html) for them. (#888 CloudXRLauncher and RigLauncher still needs to be deduped).