fix(desktop): give gateway-specific recovery for updater blockers

[skyzea1]

Summary

On Windows, an older or stale Desktop updater can still report a real Hermes gateway as a venv blocker. The resulting dialog only says to close a terminal/app/service, even though the process is a Hermes gateway and the correct recovery is hermes gateway stop followed by retrying the update.

This patch adds a conservative compatibility check for the exact python -m hermes_cli.main gateway run shape and appends gateway-specific recovery guidance. It does not change the blocker decision, stop processes automatically, or replace the Python updater's canonical gateway classification. Generic blockers keep the existing message.

Reproduction evidence

The attached screenshots show the full flow:

1. Update available dialog
2. Hermes restarting while the updater takes over
3. Update aborting with PID 20132 and python.exe -m hermes_cli.main gateway run

Related

• Related to Bug: Desktop self-update always aborts when a non-Desktop-owned gateway process holds the venv lock (Windows) #75334 and merged gateway handling in fix(update): let Windows desktop updates pause gateway processes instead of aborting #75881.
• This is separate from Update aborted by a non-Hermes python -m http.server process inside the install dir; dialog gives misleading 'Close other Hermes windows' advice #77422/fix(update): exempt non-Hermes venv module holders from update preflight (#77422) #77864, which concerns non-Hermes Python processes such as python -m http.server.

Validation

• npm run test:desktop:platforms -- electron/venv-blocker-scan.test.ts — 24 passed
• npm run typecheck — passed
• targeted ESLint — passed
• Prettier check — passed
• repository lint — passed with 88 pre-existing warnings in unrelated files

Screenshots will be attached to this description.

[skyzea1]

Closing this PR to avoid duplicating the direct fix in #78095. Review confirmed that the underlying failure is the 120-character command-line truncation that hides the trailing gateway run tokens during preflight classification. The screenshots are being added as reproduction evidence to #78095 instead.

The compatibility-message change in this PR is not the correct primary fix for the reported failure.