fix(windows): discover S4U gateways from profile PID files

[Sagittarius987]

Summary

• include validated per-profile PID/lock records in all-profile gateway discovery
• preserve existing service/process-table fallbacks, PID exclusions, and deduplication
• allow hermes update to pause Windows S4U/Session 0 gateways whose command lines are inaccessible to CIM, WMIC, or psutil

Problem

On Windows, an S4U Scheduled Task runs in Session 0 without an interactive logon. The gateway remains visible by PID, and its validated profile gateway.pid/runtime lock remains readable, but an unelevated interactive updater may receive no CommandLine or ExecutablePath from CIM/WMIC/psutil.

find_gateway_pids(all_profiles=True) previously skipped the current-profile PID lookup and depended on service/process-table discovery. That meant the updater could miss an S4U gateway during its pause phase, then correctly abort later when the venv-holder guard found the still-running Python process.

This complements the broader Windows update recovery work discussed in #53124: that PR explicitly identified S4U/Session 0 command-line visibility as an uncovered case.

Fix

When all_profiles=True, merge the already-validated records returned by find_profile_gateway_processes() before the existing service and process-table scans. _append_unique_pid() continues to enforce caller exclusions, self-PID rejection, and deduplication.

The regression test models inaccessible process argv and verifies that:

• the profile PID is still discovered
• exclude_pids is propagated and enforced defensively
• a PID repeated by service discovery is returned only once

Verification

• native Windows isolated per-file runner: 26 passed
• python -m py_compile hermes_cli/gateway.py tests/hermes_cli/test_update_concurrent_quarantine.py
• git diff --check origin/main...HEAD
• independent pre-commit review: no security concerns or logic errors
• real S4U Scheduled Task validation on Windows 11 IoT Enterprise LTSC 2024 (Session 0):
  • before the fix, all-profile discovery missed the live gateway while profile PID discovery found it
  • after the fix, all-profile discovery returned the profile PID
  • update pause released all Hermes venv holders
  • resume relaunched the gateway with a new validated PID

Scope

Two files only; no account names, task names, machine paths, or deployment-specific process names are hardcoded.

[teknium1]

Thanks for the focused Windows recovery fix. Current main still skips profile PID-file discovery when find_gateway_pids(all_profiles=True) is used (hermes_cli/gateway.py:606-624), while the update pause path depends on that all-profile result (hermes_cli/update_cmd.py:2710).

The proposed call to find_profile_gateway_processes(exclude_pids=_exclude) uses the existing validated profile source (hermes_cli/gateway.py:628-652), and _append_unique_pid preserves exclusion, self-PID, and duplicate handling (hermes_cli/gateway.py:326-333). The regression test in commit d5601b4f exercises the inaccessible-command-line case and duplicate service discovery.

Automated hermes-sweeper review.