Summary

This brings the supervised Docker paths back in line with the HOME invariant introduced for the main container command path.

docker/main-wrapper.sh already resets HOME=/opt/data before dropping from root to the hermes user, but the supervised dashboard run script and dynamically generated s6 gateway run scripts were still inheriting HOME=/root from with-contenv. That left a parity gap between the direct CMD path and the supervised s6 paths.

Parity Source

This PR is a parity follow-up to:

• 628aaea
• fix(docker): propagate env through s6 to cont-init and main CMD

That commit established the invariant that container processes running as the hermes user should resolve HOME under /opt/data, not /root. This PR applies the same invariant to the remaining supervised sibling paths.

Problem

After with-contenv, supervised services can still see HOME=/root unless they explicitly reset it before s6-setuidgid hermes.

That meant:

• docker/s6-rc.d/dashboard/run could still run with root HOME semantics
• dynamically generated profile gateway run scripts from S6ServiceManager._render_run_script() could do the same

In practice, HOME-anchored state could end up resolving under /root or fail on permissions, depending on the library/tooling involved.

Fix

• Add export HOME=/opt/data to docker/s6-rc.d/dashboard/run
• Add export HOME=/opt/data to the generated s6 gateway run script in hermes_cli/service_manager.py
• Add regression coverage for both paths

Files Changed

• docker/s6-rc.d/dashboard/run
• hermes_cli/service_manager.py
• tests/hermes_cli/test_service_manager.py
• tests/test_docker_home_override_scripts.py

Testing

Tests run

.venv\Scripts\python.exe -m pytest -o addopts= tests\hermes_cli\test_service_manager.py::test_render_run_script_resets_home_before_exec tests\test_docker_home_override_scripts.py -q

2 passed in 0.23s