probeWindowsRemote took `$env:HERMES_HOME` at face value. A stale
User-scope value on the remote (install.ps1 persisted one before
47f4ab3a17 stopped doing so; nothing removes it) or a client path
leaked over the SSH channel then flowed straight into
assertSafeRemoteHome and every Windows remote failed with
"Unsafe remote Hermes home" even though the remote install was fine.
Only honour HERMES_HOME when it names an existing directory on the
remote; otherwise fall back to the remote's default
%LOCALAPPDATA%\hermes, exactly as an unset variable does. The
installer/updater half of the report is already fixed on main:
scripts/install.ps1 no longer calls
[Environment]::SetEnvironmentVariable("HERMES_HOME", ..., "User")
(47f4ab3a17), and the updater's "Refreshed Windows gateway launcher
scripts" step only rewrites gateway.cmd/.vbs with a process-scoped
`set HERMES_HOME=`; it never persisted anything.
Slim redo of #119022 by @MohamadKanso, which reached for the User/Machine
registry scopes instead of a remote existence check.
a767190e84