Bug Description

On Windows, every hermes update reports a false positive concurrent instance error and aborts, because the setuptools-generated hermes.exe launcher is detected as a separate running instance of Hermes.

Root Cause

The setuptools launcher (hermes.exe) is a separate native process that spawns python.exe (the interpreter that runs the update code). os.getpid() returns the Python PID, but the launcher (which holds the file lock that prevents the update from renaming/quarantining the .exe) is the parent process. The old code only excluded the Python PID itself via exclude_pid = os.getpid(), so the launcher process was always flagged as a concurrent instance.

Fix

Build an exclusion set containing the Python process and its entire ancestor chain by walking psutil.Process.parent() upward. This ensures the running hermes update invocation never reports any process in its own tree — whether it's the Python interpreter, the .exe launcher, or any shell in between.

How to Verify

1. On a Windows machine, run hermes update without this fix — it fails with a concurrent-instance error.
2. Apply the patch — the same command succeeds.
3. Running hermes update with a second Hermes process (e.g. desktop app) still correctly blocks, since the other process is outside this process's parent chain.

Test Plan

• Existing tests pass
• Manual verification on Windows (the existing test suite mocks psutil; the real fix is exercised by the update flow itself)

Risk Assessment

Low — Only affects the Windows concurrent-instance detection path. The change expands the exclusion set from a single PID to the full parent chain; all other logic (shim comparison, process enumeration) is unchanged. Off-Windows the function returns [] early, so no effect on Linux/macOS.