…ss HOME (NousResearch#12260)

``agent.skill_utils.resolve_skill_config_values`` expanded ``~`` in
skill config defaults using ``os.path.expanduser``, which resolves
against the Python process's own ``HOME`` (e.g. ``/opt/data`` or
``/root`` in Docker).  Hermes independently sets a *different* ``HOME``
— ``{HERMES_HOME}/home/`` via ``hermes_constants.get_subprocess_home``
— for every subprocess it spawns (Bash, background processes, terminal
launchers).

The result: a skill declaring ``default: "~/wiki"`` surfaced
``/opt/data/wiki`` in the prompt, but subprocess tools spawned by the
agent (``wiki init``, ``bash -c 'ls ~/wiki'``, …) resolved ``~`` to
``/opt/data/home/wiki``.  Files written by one tool weren't findable
by the next.  Reporter: NousResearch#12260.

Root cause
----------
``agent/skill_utils.py:407-408`` (pre-fix)::

    if isinstance(value, str) and ("~" in value or "${" in value):
        value = os.path.expanduser(os.path.expandvars(value))

``os.path.expanduser`` uses ``os.environ['HOME']`` (the Python process
HOME) — which ``hermes_constants.get_subprocess_home``'s docstring
explicitly calls out as "**never** modified — only subprocess
environments should inject this value."

Fix
---
Add a small ``_expanduser_for_subprocess(path)`` helper that:

* Uses ``get_subprocess_home()`` when active (``{HERMES_HOME}/home``
  exists on disk).  ``~`` → subprocess HOME; ``~/…`` →
  ``{subprocess_home}/…``.
* Falls through to ``os.path.expanduser`` when the subprocess HOME
  isn't active — preserves the original behaviour for setups that
  never activated per-profile HOMEs.
* Leaves ``~user`` forms to ``os.path.expanduser`` — those name a
  specific OS user via the passwd database and are independent of
  Hermes.

``resolve_skill_config_values`` uses the new helper instead of
``os.path.expanduser`` directly.  No other callers of
``os.path.expanduser`` are touched — e.g. ``get_external_skills_dirs``
at ``skill_utils.py:212`` reads directories for the **Python process**
to load skills from, so expanding against the process HOME is correct
there.

Narrow scope — explicitly not changed
-------------------------------------
* **Other ``expanduser`` call sites.**  Only the skill config surface
  (``resolve_skill_config_values``) feeds into subprocess-facing
  prompts.  The rest of the codebase (external skills dirs, auth file
  paths, etc.) correctly targets the Python process.
* **Subprocess HOME activation logic.**  Unchanged — still controlled
  by the presence of ``{HERMES_HOME}/home/`` on disk.
* **``${VAR}`` env expansion.**  Still runs via ``os.path.expandvars``
  before ``~`` expansion; unchanged semantics.

Regression coverage
-------------------
``tests/agent/test_skill_config_subprocess_home.py`` is new, 13 cases
across two classes:

* ``TestExpanduserForSubprocess`` — 6 unit tests for the helper:
  ``~/x``, ``~``, ``~/a/b/c``, absolute paths, ``~user`` fall-through,
  no-subprocess-home fallback.
* ``TestResolveSkillConfigValuesHOME`` — 7 end-to-end tests through
  the public API: reporter scenario, no-subprocess-home fallback,
  explicit config value expansion, absolute default unchanged,
  ``${VAR}`` interaction, non-string value pass-through, empty-default
  canary.

Bug also verified to reproduce on clean ``origin/main`` (``6fb69229``)
via a direct Python repro showing
``{'wiki.path': '/home/testuser/wiki'}`` when the expected value is
``{'wiki.path': '{HERMES_HOME}/home/wiki'}``.

Validation
----------
``source venv/bin/activate && python -m pytest
tests/agent/test_skill_config_subprocess_home.py -q`` → **13 passed**.

Broader agent + skills suite (``tests/agent/`` + ``tests/hermes_cli/
test_skills_config.py`` + ``test_chat_skills_flag.py`` +
``test_skills_hub.py`` + ``test_banner_skills.py`` +
``tests/cli/test_cli_preloaded_skills.py`` + ``tests/tools/
test_skill_manager_tool.py`` + ``test_skills_tool.py``) under
``-n auto`` → **1566 passed, 1 skipped, 0 failures.**

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>