fix(update): classify long gateway command lines in desktop preflight

[burak33bb]

What does this PR do?

Fix the Windows Desktop update preflight incorrectly reporting a running Hermes
gateway as a non-pausable venv blocker when the gateway uses a long managed
runtime path.

_detect_venv_python_processes() intentionally caps captured command lines at
120 characters for display. A .hermes-runtime interpreter path can exceed
that limit before the trailing -m hermes_cli.main gateway run tokens. The
preflight therefore classified only the truncated prefix, failed to recognize
the process as a pausable gateway, and aborted the update before the CLI
updater could pause it.

The preflight now re-reads the process's live, complete argv only for gateway
classification. It keeps using the captured 120-character prefix for JSON and
diagnostic output. If the process exits or cannot be inspected, classification
fails closed and the holder remains a blocker.

Related Issue

Fixes #78089.

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻️ Refactor (no behavior change)
• 🎯 New skill (bundled or hub)

Changes Made

• Add _is_pausable_gateway_process() in
  hermes_cli/_scan_venv_blockers.py to classify a holder from its complete
  live argv when the captured prefix is insufficient.
• Preserve the existing bounded/redacted command line in preflight output.
• Preserve fail-closed behavior when process inspection fails.
• Classify each holder once and reuse the result for blocker output and the
  pausable_gateways count.
• Add a regression test using a managed-runtime path long enough to hide the
  trailing gateway command beyond character 120.

Duplicate Check

Searched open and closed issues and PRs using the issue number, exact symbols,
the 120-character truncation, venv-blocked, and pausable-gateway terminology.
No PR addresses this root cause.

• fix(update): let Windows desktop updates pause gateway processes instead of aborting #75881 introduced the pausable-gateway exemption that this fix makes reliable
  for long runtime paths.
• fix(desktop): prevent venv-blocker probe failure crash and ensure clean update process teardown #78012 hardens probe error handling and per-process failures.
• fix(update): unblock Desktop preflight and updater handoff #74599 improves Windows process-scan performance and updater handoff.
• fix(update): re-check venv holders before dependency sync to catch respawned gateways #77418 handles gateways that respawn later during dependency synchronization.

Those changes are related but do not restore the full argv before the Desktop
preflight classifies the gateway.

How to Test

1. Run the focused updater suites:

   scripts/run_tests.sh \
     tests/hermes_cli/test_scan_venv_blockers.py \
     tests/hermes_cli/test_update_venv_health.py \
     tests/hermes_cli/test_update_concurrent_quarantine.py

2. Confirm all 40 tests pass.

3. Run lint and the Windows compatibility scan:

   ruff check hermes_cli/_scan_venv_blockers.py \
     tests/hermes_cli/test_scan_venv_blockers.py
   python scripts/check-windows-footguns.py \
     hermes_cli/_scan_venv_blockers.py \
     tests/hermes_cli/test_scan_venv_blockers.py

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: Windows 11

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — N/A; behavior is covered by the helper docstring
• I've updated cli-config.yaml.example if I added/changed config keys — N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide
• I've updated tool descriptions/schemas if I changed tool behavior — N/A

Screenshots / Logs

Before fix: 23 passed, 1 failed
After fix:  24 passed, 0 failed
Expanded updater suites: 40 passed, 0 failed
Ruff: All checks passed!
Windows footgun scan: No Windows footguns found (2 files scanned)

[skyzea1]

Windows reproduction evidence

These screenshots document the user's real Desktop update flow on Windows 10:

1. Update available

   

2. Hermes restarting for the update

   

3. Update aborted

   

The visible holder is PID 20132 running python.exe -m hermes_cli.main gateway run. These images come from an older/stale installation whose displayed path is short; they are evidence of the same gateway-blocker update flow, not a claim that this exact displayed command exceeds 120 characters. The direct regression covered by this PR is the current-main case where a longer managed-runtime path truncates the trailing gateway run tokens before classification.

[teknium1]

Thanks @burak33bb. The defect this targets — the 120-char cmdline capture in _detect_venv_python_processes() hiding the trailing gateway run tokens behind long managed-runtime interpreter paths — was fixed on main in commit 0b33ee88e4 (2026-08-08): the detector now returns the FULL cmdline and truncation happens only at display time, so _is_pausable_gateway always sees the whole argv and no live-argv re-read is needed.

The earliest PR in this truncation cluster was #77754 (@stormhierta, whose full-cmdline approach is what main adopted); your live-argv re-read variant and #79195's are both superseded by the root-cause fix. Closing as implemented-on-main — regression test test_main_gateway_with_long_managed_runtime_path_is_exempt now pins this on main.