Add experimental per-session Steam isolation and game launcher

[bendaali]

Launching Steam in multiple Windows seat sessions can connect a launch to another client or leave games unable to find the intended Steam instance. This adds an optional native supervisor and targeted Steam hooks, plus service integration and an EXE picker for direct game launches. The feature defaults to disabled and is proposed as a draft for compatibility review.

Changes

• Wrap explicit absolute steam.exe launches from the service's dashboard/app and launch-on-connect paths when SteamIsolationEnabled is enabled. Validate executable/hook architecture and fail the launch if required components are missing.
• Build x64/x86 supervisors and hook DLLs. Use a session/user-derived Steam IPC name, propagate it through child environments, separate browser cache/log paths, and handle Steam's temporary launch registry values and successful DWORD SteamPID reads.
• Initialize hooks before Steam's primary thread runs, signal readiness through a protected service-owned event, and terminate incomplete launches on cancellation or timeout. Keep supervision across same-architecture Win32 Steam restarts, with job-object cleanup of supervised descendants.
• Add a standalone EXE picker that passes the matching IPC environment to a directly launched game without injecting it. Such games are outside the supervisor's job and must be closed separately.
• Document builds, configuration, explicit Apollo commands, existing IPC-based alternatives, and limitations. Vendor MinHook v1.3.4 with its license and add native CI checks.

The IPC technique predates this work; steam-multibox-easysetup is a simpler existing alternative. This PR does not claim general superiority over that approach.

Validation

• Full managed test suite: 1,469 passed, 18 skipped, no failures, including launch-plan and readiness tests.
• Release native builds and policy tests for x64 and x86.
• Harmless executable fixtures for quoting, IPC and explicit child environments, browser cache/log paths, registry data types, same-architecture replacement Steam processes, readiness failures, 64-to-32-bit delegation, and descendant cleanup.
• Direct-game smoke check verifies that the game matches the isolated Steam IPC name, uses its installation folder as the working directory, leaves the caller's environment unchanged, and receives no registry hook.
• User reported simultaneous Steam clients in a host session and a separate Windows seat, and Valheim launching through the direct-game helper. The tested game installation contained a third-party Steamworks compatibility component; this is not validation of unmodified retail Steamworks games.

Draft limitations

Real Steam updates, unmodified retail Steamworks games, anti-cheat compatibility, broad restart scenarios, and disconnect/reconnect behavior still need runtime validation. Architecture-changing replacements require relaunch through the supervisor, and replacements bypassing Win32 process creation have not been validated. Apollo launches bypass automatic service wrapping and require the documented explicit launcher command. Native binaries must be built and deployed separately; this PR does not publish release binaries.

[vibesoftwarecoder]

Thank you for this, and for the care in it. The problem is real. On our own host, starting Steam in one Windows session without an override can deliver its command line to another session's Steam. We reproduced it.

We read the whole change line by line, including the native code. We found no network access, no persistence and no privilege changes. We also found no memory-safety bugs. The bundled MinHook matches upstream v1.3.4. The hook DLL loads only into steam.exe, and the shipped default is off.

We can't merge it yet. These are the things we'd need changed:

1. The Steam check is by name only. SteamIsolationLaunchPlan.cs lines 24-25 decide on Path.GetFileName(...) == "steam.exe". Names like steam.exe. or an 8.3 short name slip through unwrapped, with no error or log line.
2. Restart coverage. Hook.cpp hooks only CreateProcessW and CreateProcessA (lines 132-148). A restart through another creation call, or with an unquoted path containing spaces, starts a Steam with no isolation.
3. The launch wait. ProcessInjector.cs waits up to 180 seconds (line 174) while the seat is locked. The timeout errors aren't mapped to an API error, and the value isn't configurable.
4. Upgrades remove the binaries. Our installer wipes the install folder on every deploy and restores only the two settings files. The native binaries would be deleted, and with the option on, every Steam launch would then fail. The PR would need to ship them or the installer would need to preserve them.
5. The launcher is a console program (add_executable without WIN32, with CREATE_NEW_CONSOLE). Each launch probably shows a console window in the seat.
6. Test gaps.
   • Nothing exercises ProcessInjector.
   • There is no negative test that another user can't open the readiness event.
   • Nothing runs the C# and native sides together.
   • The docs claim quoting is covered, but LauncherSmoke.ps1 doesn't assert the quoted argument.

Behaviours worth documenting: every child Steam starts gets the extra environment variable, SteamPID reads return 0 inside steam.exe, and all of Steam's descendants sit in one kill-on-close job.

The case we're still working on is a plain launch, such as a Start menu shortcut. Your docs say it's outside the feature, and we agree. In our tests, a Steam started without an override still reached a seat's Steam. We don't know yet how it finds it. We're looking into it, and what we learn will decide how we handle isolation.

We're keeping this open. Would you like to make the changes above yourself, or would you like us to make them? Either works. If you'd rather make them, tell us roughly when, so we can plan around it. If you'd like us to do it, we'll build on your branch and credit you in the commits.

If neither is practical for you right now, that's fine too. We'll keep it as a reference while we work on the plain-launch case.

[bendaali]

Thank you for the thorough review and for taking the time to reproduce the issue. I really appreciate the detailed feedback and your offer to credit my contribution.

Unfortunately, I don't have enough time to continue working on the PR, and the current implementation already meets my personal needs.

I'd be more than happy for you to take over and build on my branch to address the remaining issues.

Thanks again for considering the contribution, and I'm looking forward to seeing how Multiseat evolves!

[vibesoftwarecoder]

Thank you for handing this over, and for the work behind it.

We've taken it on, as you suggested. It continued in #113, which is now merged. Your commit is the first commit of that work on master (bfc644e), with your authorship, so you stay credited in the history.

Three corrections to our review above, stated as fact:

• We said 8.3 short names slip past the Steam check. For steam.exe itself that is wrong: the name already fits 8.3 and has no alias. The real gaps were trailing dots and spaces and the default stream (steam.exe., steam.exe , steam.exe::$DATA).
• We said Hook.cpp hooks only CreateProcessW and A. It also hooks NtCreateUserProcess, which rewrites every child's command line and environment. The real gap was that only the W/A pair re-injected the hook into a restarted Steam, and that an unquoted path with spaces was not recognized.
• We said LauncherSmoke.ps1 doesn't assert the quoted argument. It does (arg5=two words). The argument with an embedded quote is not asserted.

#113 lists what we changed, what we tested and what we did not. We're closing this PR because #113 replaces it. Your branch is not touched.

Thanks again.