fix(hermes): latest version restricted write in our path

[OisinKyne]

Summary

What was happening

Neither file moves nor permissions would have helped — this isn't a filesystem/chown issue. The nousresearch/hermes-agent:v2026.7.1 image (pinned in the recent "bump image pins" commit) newly bakes HERMES_WRITE_SAFE_ROOT=/opt/data into the image env — an allowlist: when set, Hermes' file tools deny every write outside that root, with the (misleading) "protected system/credential file" error. v2026.5.7 didn't have this; I confirmed by diffing the two images' env and reading agent/file_safety.py inside the pinned image.

Upstream that default is coherent because their HERMES_HOME is /opt/data. But obol-stack relocates HERMES_HOME to /data/.hermes on the PVC and never touches /opt/data — so the safe root pointed at a directory nothing uses, and every write the agent attempted (/data/.hermes/workspace/.py, /tmp/.sh) was outside it and denied.

The fix

Override the env var to follow the relocated home, in both places that render Hermes pods:

• internal/hermes/hermes.go — stack-managed agent deployment: added HERMES_WRITE_SAFE_ROOT=/data/.hermes:/tmp (the guard supports colon-separated multi-roots; /tmp covers scratch scripts, and the static credential denylist still applies inside the roots, so the defense-in-depth is kept rather than disabled).
• internal/serviceoffercontroller/agent_render.go — CRD sub-agents (obol agent new) get the same env.
• Regression guards added to TestGenerateValues_UsesHermesNativeNames and TestAgentManifests_DeploymentEnvCarriesContext so a future image bump or env refactor can't silently drop it.