fix(gateway): make intentional systemd stops exit cleanly

[heathley]

Summary

Fix intentional systemd gateway stops being recorded as failures.

Today there are two separate failure paths behind this:

1. hermes gateway stop --system writes the planned-stop marker from a sudo/root context, so the marker can end up unreadable to the actual gateway service user.
2. Direct systemctl stop never writes a planned-stop marker at all, so the gateway cannot distinguish an intentional stop from an unexpected SIGTERM and exits with status 1 by design.

This change moves the correctness path into the systemd unit itself by adding a non-recursive ExecStop helper that writes the planned-stop marker as the service user before systemd delivers SIGTERM.

Closes #24344.

What changed

• Added an internal hermes gateway _write-planned-stop --pid <pid> helper
• Added ExecStop=... gateway _write-planned-stop --pid $MAINPID to generated systemd units
• Updated the existing CLI stop prewrite path to reuse the same helper
• Relaxed planned-stop marker read permissions after writing so cross-user stop paths remain readable by the gateway service process
• Added regression coverage for:
  • generated systemd unit includes the ExecStop helper
  • planned-stop helper writes a readable marker
  • systemd_stop() marks the stop as planned before stopping
  • internal helper command success/failure dispatch

Why this approach

This preserves Hermes' existing non-zero exit behavior for genuinely unexpected SIGTERM, which is still needed for Restart=on-failure recovery.

It intentionally does not use SuccessExitStatus=1, since that would mask real unexpected shutdown failures.

Verification

Tested with targeted regression coverage:

• tests/hermes_cli/test_gateway_service.py -k "execstop_helper or planned_stop_only or systemd_stop"
• tests/hermes_cli/test_gateway.py -k "write_planned_stop_internal_command"

[teknium1]

Thanks for tracing both the root-owned marker path and direct systemctl stop path. The premise remains valid on current main: gateway/run.py:20490-20539 treats an unmarked SIGTERM as unexpected, and gateway/run.py:20799-20804 exits 1; generated units at hermes_cli/gateway.py:2753-2801 have no ExecStop marker writer.

Problems

• Current main deliberately omits ExecStop in both templates (tests/hermes_cli/test_gateway_service.py:426-449, :537-561) after commit 002c45998, which removed a recursive hermes gateway stop ExecStop. The proposed helper is non-recursive, but this requires a deliberate salvage that preserves that distinction rather than a clean application of the stale patch.
• The added generation coverage checks only the system unit even though the diff adds ExecStop to both user and system templates.

Suggested changes

• Port the marker-only helper to the current templates and replace both existing no-ExecStop regressions with assertions that it cannot re-enter service management.
• Cover both unit scopes and the hidden command dispatch.

Automated hermes-sweeper review.