fix(harness): sessions from the desktop processes' owners, matched by SID

[fadwen]

Summary

-Credential on the harness commands decided between an interactive task and a stored-password task by parsing query user. Windows Home editions do not ship query.exe, so every run there fell back to the stored-password task, and the tool's output is localized, so the parse depended on the device's language. The session list now comes from the owners of each desktop's explorer.exe and sihost.exe through CIM, and the account is matched by its SID.

Follows #6, which resolved the credential's name to the account Windows means but still matched the session on the resulting name.

Changes

• Get-IslLogonSession. Lists one session per desktop user from Win32_Process (explorer.exe, or sihost.exe while the desktop is still starting), with the owner's name and domain from GetOwner, the SID from GetOwnerSid, and the session id. A process whose owner cannot be read is left out. Reading another account's process owner needs an elevated session, which the credential launch needs anyway.
• Invoke-IslProcess. Matches the session by SID when Resolve-IslAccount resolves the credential's name, by the owner's name as text otherwise.
• Get-IslQueryUserOutput removed with its only caller.
• Tests. Get-IslLogonSession over mocked CIM: one session per user from several shell processes, a session with sihost.exe alone, an unreadable owner left out, no desktop at all, and the real machine for shape. Launcher tests carry the new session shape (Sid, Domain).
• Documentation. Findings ("The harness as another account") records the measurement; changelog under Unreleased.

Verification

• Unit and integration suites: 927 pass on PowerShell 7.6.6 (8 skipped: elevation, lab credential); 875 pass on Windows PowerShell 5.1 for the unit suites and two integration files (33 skipped). PSScriptAnalyzer (Error and Warning) is clean; no line over 115 characters.
• Windows 11 Home (no query.exe): Get-IslLogonSession lists the console session with its SID, where the previous version returned nothing.
• Joined lab device, VM 125, the Entra test user signed in, the module run as SYSTEM: Get-IslLogonSession listed AzureAD\IslVerylongdisplayna, SID S-1-12-1-...-805488699, session 2, the SID the sign-in name resolves to; -Credential with the sign-in name, AzureAD\<sign-in name> and the Windows name each ran the script inside session 2 with interactive=True, and left no task and no run folder behind.

Notes

• Merge after perf(validation): Collect moves its payload in one guest agent call, gzipped #9 (validation kit); the two touch different files, but both add to the changelog's Unreleased section.
• The stored-password path still registers its task with the credential's name as given and is not exercised for an Entra account; that is the next change.

[fadwen]

Notes on the lines whose reason the diff does not show.

[fadwen]

CIM returns processes in no fixed order. Sorted so the output order is the same on both hosts and, where a session has both processes, the explorer.exe row is the one kept by the check below.

[fadwen]

One session can hold several of these processes: sihost.exe next to explorer.exe, and a second explorer.exe when a folder window runs as its own process. One row per session and owner is what the caller counts.

[fadwen]

The text match is the path for a name Windows cannot translate, where Resolve-IslAccount returns nothing. It keeps the behaviour from before #6 there, and the scheduler then reports the real error for the name itself.

[fadwen]

sihost.exe is listed before explorer.exe, and with the higher process id, on purpose: the result must not depend on the order CIM hands the processes back.