feat: Hermes adapter — make the viewer/daemon port overridable (currently pinned to 18800)

[chiefmojo]

Pre-submission checklist | 提交前检查

• I have searched existing issues and this hasn't been mentioned before | 我已搜索现有问题，确认此问题尚未被提及
• I have read the project documentation and confirmed this issue doesn't already exist | 我已阅读项目文档并确认此问题尚未存在
• This issue is specific to MemOS and not a general software issue | 该问题是针对 MemOS 的，而不是一般软件问题

Problem Statement | 问题陈述

The Hermes adapter pins the viewer/daemon port to 18800 with no override, so on a host where a Hermes gateway is already running there is no supported way to bring up a second MemOS instance on a different port — for example to point a measurement harness at an isolated MEMOS_HOME snapshot, or to run a dev instance alongside a production one.

Verified against main (176d4f67):

1. The port is a module constant, and the design is explicitly a singleton.
apps/memos-local-plugin/adapters/hermes/memos_provider/daemon_manager.py:55 → HERMES_VIEWER_PORT = 18800. It is used by the health probe (:287, :291), the daemon spawn and its readiness checks (:391, :398, :416, :423, :476, :481), and the zombie scan matches the literal ":18800" (:534, :547). The docstring at :364 states it: "Ensure the singleton Hermes Viewer daemon owns :18800."

2. The config field exists but its value is discarded.
memos_provider/__init__.py:1693-1697 exposes a viewer_port setup field (default 18800), but save_config (:1744-1748) ignores what the user supplied and writes 18800, with the comment "the Hermes adapter owns :18800. Persist the effective value so the YAML file never advertises a port the runtime will not bind."

3. No environment override exists.
The adapter reads MEMOS_HOME, MEMOS_CONFIG_FILE, MEMOS_HERMES_BRIDGE_MODE, MEMOS_HERMES_LONG_RPC_TIMEOUT, MEMOS_HERMES_PREFETCH_RPC_TIMEOUT and MEMOS_NODE_BINARY. None of them is the port.

The consequence is that the singleton assumption is unfalsifiable: a second instance cannot be isolated, because every probe and every client resolves to 127.0.0.1:18800 regardless of which home that instance was given. Setting MEMOS_HOME to a scratch home is not enough on its own — the listener it should be talking to is the one already running.

Related but distinct: #2212 (closed) covers the viewer UI clobbering viewer.port; its resolution keeps the adapter owning the value. This request is the inverse — an explicit, opt-in override.

Proposed change: read the port from an environment variable (e.g. MEMOS_VIEWER_PORT, name at your discretion) when resolving the viewer runtime, defaulting to 18800, and use that value in the probe, the daemon spawn/readiness checks, the zombie scan and any HTTP client. Honour a configured viewer_port rather than discarding it. With the variable unset, production behaviour is byte-for-byte unchanged.

Willingness to Implement | 实现意愿

• I'm willing to implement this myself | 我愿意自己解决
• I would like someone else to implement this | 我希望其他人来解决

[chiefmojo]

Closing this — our case is resolved, and I don't want to hold a status:ready slot for something we no longer need.

What changed on our side: we were running a fork-local carry of the half-merged HTTP bridge transport (the one #2096 removed and now guards against), which made every client resolve to the daemon on :18800 regardless of its own MEMOS_HOME. We've since ported shared_bridge_runtime.py and runtime_home.py verbatim, and the memory path now acquires a shared stdio bridge keyed on (resolved_home, "hermes", "stdio"). Isolation works, nothing connects to :18800, and no override is needed.

I also understand the pinning better than when I filed this: save_config deliberately discards a supplied viewer_port and writes 18800 so the config never advertises a port the runtime won't bind, and the daemon is documented as a singleton. That's coherent for the viewer — the request above was really asking you to work around our own divergence.

The observation stands on its own: on a host with two Hermes gateways, the second viewer can't move off :18800. But that's speculative for us now, so it's your call whether it's worth having. Reopen or re-file if it is — happy to give details.