Chat-composer attachment paths aren't visible inside terminal.backend: docker sandboxes

Summary

api/upload.py's handle_upload() saves chat-composer attachments to _attachment_root() (HERMES_WEBUI_STATE_DIR/attachments/<session_id>/<filename> by default, or HERMES_WEBUI_ATTACHMENT_DIR when configured), and api/streaming.py embeds that literal absolute host path into the user's message text via [Attached files: <path>].

When the hermes-agent tool-execution code this project runs in-process has terminal.backend: docker configured, tool calls (e.g. read_file) run inside a sandboxed Docker container via docker exec, with the literal path string passed through unchanged - hermes-agent's tools/file_tools.py performs no host-to-container path translation for Docker-backend sessions (confirmed from source). The sandbox container never has the webui's attachments directory bind-mounted into it at all (hermes-agent's own _CACHE_DIRS auto-mount list covers its own native upload channels - Desktop/TUI file.attach, gateway platform media caches - but has no entry for this project's independently-built /api/upload attachments directory).

Net effect: a user uploads a file via the chat composer, the model is given a real, correct absolute path, and any tool call against that path fails with "no such file or directory" inside the sandbox - the model has no way to know it needs a different path form, because there isn't one it could ask for.

Confirmed live

[Attached files: /home/hermeswebui/.hermes/webui/attachments/<session>/photo.jpg]

...is not visible inside the active terminal.backend: docker sandbox container (confirmed via docker inspect's mount list and a direct ls inside the container), even though hermes-agent's own native upload mechanisms (Desktop/TUI attach) have a dedicated, tested translation function for exactly this class of problem (tools/credential_files.py::to_agent_visible_cache_path()) - this project's /api/upload never calls it, and has no way to (it's an internal, unexported hermes-agent function, not something this project could call across the process boundary even if it wanted to).

Suggested fix directions

1. If hermes-agent exposes (or would expose, see the issue I'm filing there) a small public API/CLI to translate a host path into its sandbox-visible form, call it before embedding the path in [Attached files: ...] when a container backend is active.
2. Document HERMES_WEBUI_ATTACHMENT_DIR as needing to point at a location that's actually bind-mounted into the active sandbox backend when one is configured - today's docs for that env var only discuss keeping uploads out of the active workspace, not sandbox visibility at all (per the existing issue that introduced it, #2247, which explicitly disclaims this).
3. Consider routing attachments through the same reference-token mechanism hermes-agent's own Desktop/TUI file.attach RPC uses (@file:<ref>, expanded via agent/context_references.py, which does call the translation function) instead of a bare host path string, if there's a supported way for a frontend to trigger that expansion path.

Happy to share our specific compose/mount setup if useful for repro.