fix(install): kill venv-resident gateway before recreating venv on Windows

[Danamove]

Problem

On Windows, the desktop app re-runs scripts/install.ps1 on every launch. When an update is pulled it recreates the venv. The existing guard before Remove-Item venv only does:

& taskkill /F /T /IM hermes.exe /FI "PID ne $myPid"

That misses the most common lock-holder. The gateway/agent that a scheduled task or watchdog autostarts runs as:

pythonw.exe -m hermes_cli.main gateway run    # straight out of venv\Scripts\

Its image name is python/pythonw, not hermes.exe, so taskkill /IM hermes.exe never matches it. It keeps the venv's native extensions loaded (observed on tornado\speedups.pyd; also _bcrypt.pyd), so the next line fails:

venv → FAILED: Cannot remove item ...\venv\Lib\site-packages\tornado\speedups.pyd:
Access to the path 'speedups.pyd' is denied.

The bootstrap aborts at the venv stage and the desktop never loads — even though killing the leftover gateway and relaunching fixes it every time.

Fix

Keep the existing hermes.exe taskkill, and additionally stop any process whose executable lives under the venv being deleted, matched by path (ExecutablePath -like "$venvRoot\*") so:

• the image name is irrelevant (python.exe / pythonw.exe / hermes.exe all caught), and
• a global/system Python outside the venv is never touched, and the installer's own PID is excluded.

Scoped to Install-Venv, Windows-only, no behavior change on other platforms.

Test

• [System.Management.Automation.Language.Parser]::ParseFile(...) → parses cleanly.
• Reproduced the original failure on a live install (gateway autostarted from venv\Scripts\pythonw.exe locking speedups.pyd); with the leftover venv-resident process stopped, Remove-Item venv and the full bootstrap (venv → dependencies → … → ready) complete.

🤖 Generated with Claude Code

[jquesnelle]

Superseded by #52044