Orchestrator --with-demos installs demos; --with-demo-sources clones (#297)

[dfattal]

Closes #297.

What

Splits the dev orchestrator's demo handling into two intent-revealing flags:

Flag	Behavior
--with-demos	Installs each demo's prebuilt release asset — gh release download + silent install + marker check, the same install_component path as runtime/shell/leia/mcp.
--with-demo-sources	Clones each displayxr-demo-* repo into ./demos/<name>/ (the former --with-demos behavior), for contributors who build from source.

Both combine freely; --dry-run works with both.

Why (the resilience argument)

The original clone-only choice (#283) was to avoid importing each demo's build environment (Vulkan SDK, graphics toolchains) onto the contributor's box. But clone-only doesn't make a demo usable — it leaves the dev to build it, which is exactly where that fragility bites; after --with-demos the shell launcher showed no demo tile (the bug #297 was filed for).

Installing a prebuilt release asset sidesteps the build entirely — the binary was already compiled by the demo's own CI — so --with-demos is more resilient to dev-environment drift, not less. Source-only demos (no release installer) stay under --with-demo-sources.

How

• components.sh: new COMPONENT_PIN_KEY_<name> override (the demo's tag lives at demos.gaussiansplat, not a top-level key) + a DEMO_COMPONENTS list. install_component resolves the pin key, defaulting to the component name.
• setup-displayxr.sh / .bat: --with-demos now loops DEMO_COMPONENTS through install_component (after the core components, so runtime is present for demos that require it); --with-demo-sources carries the old clone loop. Demos with no asset for the current OS warn-and-skip (no hard failure).
• full-stack-install.md: documents the split.

#311 already registered gauss_demo in the component table; this PR wires it into the install path. Bridges the gap until #284's user-facing meta-installer ships.

Test

• bash -n clean on .sh + components.sh; --help renders the new flags.
• Pin-key resolution verified: runtime → runtime, gauss_demo → demos.gaussiansplat → v1.4.1.
• .bat mirrors the same structure (exact-match arg parse; --with-demos doesn't shadow --with-demo-sources).

🤖 Generated with Claude Code

[dfattal]

Validated with a real macOS install (./scripts/setup-displayxr.sh --with-demos):

• Runtime .pkg installed → installer: The upgrade was successful → ✅ runtime installed.
• --with-demos resolved gauss_demo via the new demos.gaussiansplat pin key → v1.4.1, downloaded DisplayXRGaussianSplat-1.4.1.pkg → ✅ gauss_demo installed.
• Smoke verification green; all three markers confirmed present afterward: runtime sim-display manifest, /etc/xdg/openxr/1/active_runtime.json, and /Applications/Gaussian Splat Viewer.app.

The run also surfaced a latent robustness bug (pre-existing in install_component, now exercised by the demo path): a transient gh broken-pipe on the asset-count query left asset_count empty and [ "$asset_count" -eq 0 ] aborted with integer expected. It happened to fall through and install anyway, but that was accidental. Fixed in 8cc17e93d — the integer test is now guarded by a numeric match, so a network blip falls through to the download (the real gate) cleanly instead of printing a scary error.