Orchestrator --with-demos should also install demos (not just clone source)

[dfattal]

Today

scripts/setup-displayxr.{sh,bat} --with-demos only clones each displayxr-demo-* repo into ./demos/<name>/. It does not install. That was intentional in #283 because demo builds were API-specific and pre-#284 most demos didn't have a one-line installer to run.

What changed

Demos with .exe / .pkg releases now exist — displayxr-demo-gaussiansplat v1.3.1 ships DisplayXRGaussianSplatSetup-1.3.1.exe today, and the meta-installer scope from #284 will pin one or more demos into the bundle. For those demos, the orchestrator could trivially gh release download + start /wait "" $exe /S exactly like it does for runtime / shell / leia / mcp — that table of (repo, exe-glob, marker-key) is already the right shape.

Why this matters now

On a fresh dev box doing setup-displayxr.bat --with-demos:

• Today: clones to ./demos/displayxr-demo-gaussiansplat/, but the shell launcher shows no Gaussian Splat tile and the demo isn't usable. The contributor has to find the .exe on the demo's release page and double-click it separately — not a one-command setup.
• With this change: every pinned demo with a release asset is installed silently in the same pass as the runtime/shell/leia/mcp components. The shell launcher's manifest scan picks them up on next launch.

Proposed shape

1. versions.json: already has demos: { gaussiansplat: "v1.3.1" }. Reuse as-is.
2. scripts/lib/components.sh: add COMPONENT_REPO_demo_<name> / COMPONENT_EXE_demo_<name> entries for each demo with a release. Asset glob is the per-demo DisplayXR<Demo>Setup-*.exe.
3. scripts/setup-displayxr.bat + .sh: when --with-demos is set (or a new dedicated --install-demos flag), iterate versions.json's demos map and call the existing install_component subroutine for each. Same elevation / asset-attached / marker-check semantics — zero new code path.
4. Backwards compat: keep the existing gh repo clone behavior either as a separate --with-demo-sources flag or as a sibling of --install-demos. Contributors building from source still want the clone.

Coordination with #284

This is probably the wrong place for it long-term — once #284's displayxr-installer meta-installer ships, end users will get the demos via the bundle, not via the dev orchestrator. The orchestrator is dev-facing.

But the orchestrator is also a dev's only one-command path until #284 lands, and #284 doesn't have an ETA. Two ways to think about it:

• (A) Land in the orchestrator now, retire when User meta-installer: one-download full-stack DisplayXR for end users (new displayxr-installer repo) #284 ships. Cheap (~30 line diff per OS). Bridges the gap; one place for a contributor to discover what "full stack" means today. When User meta-installer: one-download full-stack DisplayXR for end users (new displayxr-installer repo) #284 ships, deprecate the orchestrator-side demos in favor of pointing at the bundle.
• (B) Wait for User meta-installer: one-download full-stack DisplayXR for end users (new displayxr-installer repo) #284 and don't bloat the orchestrator. Keeps the dev script narrowly scoped at runtime/shell/leia/mcp. Contributors continue to install demos manually until the bundle ships.

I'd weakly recommend (A) if #284 is more than ~1 month out; (B) if it's imminent.

Why this is filed against the runtime repo

The orchestrator lives in displayxr-runtime/scripts/. Filing here keeps the implementation discussion next to the code. Linked to #284 since the user-facing bundle work supersedes this in the long run.

Surfaced by

Tail-of-the-week e2e test on #291. After setup-displayxr.bat --with mcp the shell launcher had no Gauss tile until I separately ran the demo installer. See DisplayXR/displayxr-demo-gaussiansplat#10 for the related demo-side uninstaller fragility found in the same trace.

Linked: #284