Plugin reads stale DISPLAYXR_SHELL_SESSION env var (runtime renamed to DISPLAYXR_WORKSPACE_SESSION)

[dfattal]

Bug

The plugin's native shell-mode detection reads DISPLAYXR_SHELL_SESSION, but the runtime renamed this env var to DISPLAYXR_WORKSPACE_SESSION as part of the brand-separation work in DisplayXR/displayxr-runtime-pvt#186. The DisplayXR Shell binary now launches apps with DISPLAYXR_WORKSPACE_SESSION=1 only — the old var is never set.

Result: displayxr_is_shell_mode() returns 0 under any current workspace controller, and the C# layer thinks the app is running standalone.

Knock-on symptoms

1. Runtime/DisplayXRFeature.cs:141-146 — runInBackground is no longer enabled when launched from a workspace controller. Unity stops processing input/rendering whenever the controller's compositor window has foreground focus.
2. Runtime/DisplayXRInputController.cs — IsShellMode() returns false → falls back to Unity's Input System, which ignores apps without foreground → mouse/keyboard input is broken in workspace-controller-launched sessions.

Scope

Coordinated rename across native + C#. Names are internal to this repo (no external SDK consumers), so no back-compat aliases needed.

Native (native~/):

• displayxr_win32.c:44 — read DISPLAYXR_WORKSPACE_SESSION instead of DISPLAYXR_SHELL_SESSION
• displayxr_win32.c:38 — s_shell_mode → s_workspace_mode
• displayxr_win32.c:41 / displayxr_win32.h:26 / displayxr_hooks.h:89 — rename exported function displayxr_is_shell_mode → displayxr_is_workspace_mode (also rename displayxr_get_shell_mouse_state → displayxr_get_workspace_mouse_state for consistency)
• displayxr_hooks.cpp:125, 598, 636 — update call sites
• displayxr_win32.c:9, displayxr_win32.h:25, displayxr_hooks.h:87 — update comments

P/Invoke (Runtime/DisplayXRNative.cs):

• Lines 88-92, 95-99 — rename displayxr_is_shell_mode and displayxr_get_shell_mouse_state DllImports + summaries

C# call sites (Runtime/DisplayXRFeature.cs, Runtime/DisplayXRInputController.cs):

• Internal helpers IsShellMode / UpdateShellMouse / ShellGet* and static caches s_shellMode / s_shellButtonsCurr etc. → workspace-mode names. Comments referencing "shell mode" → "workspace mode" or "workspace controller mode".

Out of scope

• The manifest/launcher copy already migrated to workspace-controller-agnostic terminology (see #54 and follow-up).
• The native preview window has unrelated mentions of "shell" — preserve those.

Test plan

• Build the plugin (native~/build-win.bat); rebuild a Unity sample.
• Launch the sample under displayxr-shell.exe (which sets DISPLAYXR_WORKSPACE_SESSION=1). Verify Unity continues rendering after the shell window takes focus, and mouse input passes through via the native fallback.
• Launch the sample standalone (no env var). Verify IsWorkspaceMode() returns false and Unity uses its standard Input System path — i.e. existing standalone behavior is unchanged.