Summary

When the gateway process is killed abruptly (SIGKILL, power loss, OOM)
it cannot clean up gateway.pid. On the next systemctl start, the
PID file is still present. If the old PID has been recycled by the OS,
get_running_pid() may incorrectly treat the new process as a running
gateway, blocking startup. If it correctly identifies the PID as stale,
startup proceeds but the file is left as noise until Python cleans it up.

Fix: Add ExecStartPre=-/bin/rm -f {hermes_home}/gateway.pid to
both service templates (user-level and system-level) in
generate_systemd_unit(). The - prefix makes the step non-fatal —
if the file doesn't exist or the command fails for any reason, systemd
continues. The path is the Python f-string value of hermes_home, baked
in at install time, so it targets the correct profile directory.

This is a belt-and-suspenders complement to --replace: --replace
handles live processes via Python; ExecStartPre handles the stale-file
case at the OS level before Python starts.

Changes

• hermes_cli/gateway.py — both generate_systemd_unit() templates:
  insert ExecStartPre=-/bin/rm -f {hermes_home}/gateway.pid before
  ExecStart

Related

• Windows: hermes gateway crashes on stale gateway.pid after abrupt shutdown (os.kill(pid, 0) -> OSError) #7227 / [Bug]: Windows Git Bash gateway startup can crash on stale gateway.pid when os.kill(pid, 0) raises WinError 11 #9574 — stale gateway.pid crash on Windows (same root cause,
  different platform; this fix addresses the Linux systemd path)

Test plan

• Manually verified: service starts cleanly after simulating a stale
  gateway.pid left by a killed process
• No automated tests added (existing suite requires dependencies not
  available in this environment)