[vibesoftwarecoder]

Fixes #126

When an isolated Steam blocks an upgrade, the installer prints a command to close it.
That command passed MultiSeat.SteamHook.dll after --steam.
The launcher wants the path to steam.exe there, so it printed its usage text and did nothing.

The cause was the Path field on the process list.
For a process found by a loaded module, Path holds the module that matched, not the program.
steam.exe loads the hook DLL, so its Path was the DLL.
The message builder used that Path.

Each process entry now also has an ImagePath field with the process's own exe.
It is read from the process, with a Win32_Process fallback, and is null when neither works.
The message uses the first steam entry whose ImagePath ends in steam.exe.
If there is none, it keeps the placeholder.
Path is unchanged, so nothing else that reads it is affected.

Tested:

• New tests: a holder whose Path is the hook DLL and whose ImagePath is steam.exe prints steam.exe. A holder with no ImagePath prints the placeholder. A DLL-image entry does not beat a later real steam.exe. A real running process in a temp SteamIsolation folder gets its ImagePath filled and printed.
• I reverted only the message change and confirmed the first test fails, then restored it and confirmed it passes.
• Full suite: 1643 passed, 18 skipped, 0 failed. The script lint passes under PowerShell 5.1 and 7.

Not tested: I did not re-run this against a live isolated Steam. The tests use a stand-in steam.exe. The 32-bit steam.exe fallback path was not exercised.

The two-minute delay before Steam exited, noted in the issue, is a separate question and is not changed here.

🤖 Generated with Claude Code