After migrating the gateway to run under a dedicated unprivileged system account (hermes, home at /var/lib/hermes/), running hermes update regenerates the systemd unit and writes paths pointing to the CLI user's home (/home/user/.hermes/...) instead of the service account's home (/var/lib/hermes/.hermes/...).

Steps to Reproduce

1. Migrate gateway to service account:

   This creates hermes user, copies data to /var/lib/hermes/, updates the systemd unit.

2. Verify gateway runs correctly as hermes:

   systemctl status hermes-gateway  # active, User=hermes

3. Run hermes update as the CLI user

4. Gateway fails to start:

   hermes-gateway.service: Changing to the requested working directory failed: Permission denied
   hermes-gateway.service: Failed at step CHDIR spawning /home/user/.hermes/...: Permission denied


Root Cause

hermes update regenerates the systemd unit using $HOME expansion of the CLI user running the update, not the service account. Four directives get reverted to /home/user/...:

- ExecStart
- WorkingDirectory
- Environment="PATH=..."
- Environment="VIRTUAL_ENV=..."

While User=hermes, HOME=, and HERMES_HOME= stay correct — so the unit says "run as hermes" but points to paths hermes can't traverse.

Expected Behavior

hermes update should detect a service account mismatch and either:
- Preserve the existing unit paths, or
- Derive paths from the HERMES_HOME env var (already set correctly), or
- Warn before overwriting a unit whose User= doesn't match the CLI user

Environment

- Hermes v0.13.0 (2026.5.7), git install
- Ubuntu 25.10 amd64
- CLI user: user (sudo-capable)
- Gateway user: hermes (system account, nologin, no sudo)
- Gateway home: /var/lib/hermes