fix: use absolute() instead of resolve() in _remap_path_for_user to preserve venv symlinks

[nurgeldy]

Problem

When installing a system gateway service via sudo hermes gateway install --system, the generated ExecStart points to the bare system Python instead of the venv Python. This causes ModuleNotFoundError (e.g. No module named 'yaml') because the system Python doesn't have project dependencies installed.

Root Cause

_remap_path_for_user() in hermes_cli/gateway.py uses Path(path).resolve() which follows symlinks. The venv Python (venv/bin/python) is typically a symlink to the system Python binary. After resolve(), the symlink target replaces the venv path. Since the resolved path lives under a different prefix than the current user's home, the remap returns it as-is — losing the venv context entirely.

Flow:

1. get_python_path() correctly detects venv/bin/python
2. _remap_path_for_user(python_path, home_dir) calls Path(python_path).resolve()
3. Symlink resolves to /usr/local/share/uv/python/cpython-3.11-.../bin/python3.11
4. Resolved path is NOT under /root/, so remap returns it unchanged
5. Service file gets the bare Python, not the venv Python

Fix

Path.absolute() converts relative paths to absolute without following symlinks. This preserves the venv Python path through the remapping logic.

-    resolved = Path(path).resolve()
+    resolved = Path(path).absolute()

Verification

After the fix, sudo hermes gateway install --system generates:

ExecStart=/home/user/.hermes/hermes-agent/venv/bin/python -m hermes_cli.main gateway run --replace

Instead of the previous broken output:

ExecStart=/home/user/.local/share/uv/python/cpython-3.11.15-linux-x86_64-gnu/bin/python3.11 -m hermes_cli.main gateway run --replace

[teknium1]

Already fixed on main via PR #8861 (salvage of #7735 by @akhater). The current code drops .resolve() entirely and uses .expanduser() for lexical-only expansion, preserving venv symlinks. Thanks for the contribution!