Problem

`hermes gateway run` invoked from an interactive CLI session gets a self false-positive: the `ps aux` scan in `_scan_gateway_pids` matches generic substrings like `hermes_cli.main gateway`, which picks up the invoking CLI process AND its ancestor chain (parent shell, tmux session, launcher wrapper). The gateway then concludes it's 'already running' and shuts down immediately.

Reported by @yes999zc in #13242.

Fix

`_append_unique_pid` already filtered `os.getpid()` but not the ancestor chain. The repo already has an ancestor-detection helper `_is_pid_ancestor_of_current_process` used by `_request_gateway_self_restart`. Extend `_append_unique_pid` to reuse it — one gate, covers every call site (`find_gateway_pids`, service probes, `_scan_gateway_pids`).

Pre-implement audit

• A (existing helper): `_is_pid_ancestor_of_current_process` already defined at `hermes_cli/gateway.py:150`. Reuse rather than re-walking the parent chain. ✓
• B (shared callers): `_append_unique_pid` is called from `find_gateway_pids` (service + PID-file + ps-scan paths). Adding an extra exclusion strictly narrows what's returned — existing callers that wanted to kill/probe gateway processes still get real gateway PIDs, they just stop seeing their own invoker tree. Contract preserved. ✓
• C (broader rival): No rival on gateway run detects calling CLI process as running gateway instance (self false positive) #13242. ✓

Testing

• New `test_append_unique_pid_excludes_current_process_ancestors` — monkeypatches the parent chain to return `5000 → 4000 → 1`, asserts that `_append_unique_pid` rejects both 5000 (current) and 4000 (parent), keeps only the unrelated 7777 gateway PID.
• Touched the existing `test_find_gateway_pids_falls_back_to_pid_file_when_process_scan_fails` to stub `_is_pid_ancestor_of_current_process` (so the fallback path doesn't shell out to real `ps -o ppid=` for the fake service pid 321).
• Full `test_gateway.py` + `test_gateway_service.py` suites pass (117/117).

Fixes #13242