Surface pinPeerName in hermes memory setup wizard for multi-instance Honcho setups

Problem

When running two Hermes installations that share a Honcho workspace (e.g. a cloud VPS with a Telegram gateway + a Mac CLI for browser/file work), the Telegram gateway hard-codes the Telegram user ID as the Honcho user peer name, overriding the peerName value configured in ~/.hermes/honcho.json. As a result, Honcho models the same human as two distinct user peers (e.g. alice for CLI sessions and 123456789 for Telegram messages), the dialectic synthesis builds two parallel user models, and cross-instance recall via honcho_reasoning / honcho_search returns empty across the gap.

The fix landed in #15381 as the pinPeerName: true flag (per-host or root-level in honcho.json). When enabled, the configured peerName wins and gateway IDs become the fallback.

What's working

• The flag is implemented and functional in v0.14.0 (2026.5.16) (verified by grep pinPeerName ~/.hermes/hermes-agent/)
• Test coverage exists in tests/honcho_plugin/test_pin_peer_name.py
• Once set, the Telegram → CLI peer unification works as expected

What's missing

• hermes memory setup wizard does not prompt for pinPeerName. A user setting up Honcho across two installations has no in-wizard signal that this flag exists or matters.
• The user-facing Honcho integration docs at https://hermes-agent.nousresearch.com/docs/user-guide/features/honcho do not mention pinPeerName, the related issue #14984, or the multi-instance gotcha.
• hermes honcho status does not surface the current pinPeerName value in its config block, so there's no easy diagnostic.

The default of false is correct for multi-user-bot deployments. But for the canonical single-user, multi-instance pattern (one human, many front-ends), the current default produces broken cross-instance memory silently — the symptom looks like "Honcho recall doesn't work," not "two peers are being modeled."

Suggested fix

One or more of:

1. Wizard prompt — hermes memory setup already asks the user for the AI peer name, user peer name, workspace ID, observation mode, write frequency, recall mode, context tokens, dialectic cadence, reasoning level, and session strategy. Adding one more prompt for "Single human across multiple front-ends? (pin peerName) [N]" with clear yes/no semantics would catch this at install time.
2. Docs note — the integration guide page should call out the multi-instance pattern and pinPeerName: true as the recommended setting for one-user-many-front-ends deployments.
3. hermes honcho status surface — add a line like Pin peer name: true/false so users can see the effective value without parsing honcho.json directly.
4. Smarter default — if a Hermes install ever needs to detect "the user peer name in config differs from the gateway-supplied user ID," auto-pin and log a warning. Probably more invasive than the other fixes.

Reproduction

1. Set up two Hermes installations (e.g. VPS + Mac) with the same Honcho workspace and the same configured peerName (e.g. alice) in honcho.json.
2. Enable a Telegram gateway on one instance, allowlisted to a single user ID.
3. Send a message to the bot via Telegram, then run hermes interactively on the other instance and tell the agent a fact.
4. Inspect the Honcho UI's Peers tab for the shared workspace. Observed: two user peers exist (the configured name + the Telegram user ID). Expected: one user peer.

Encountered in

v0.14.0 (2026.5.16), May 2026. Spent ~5 hours debugging the symptom before locating the pinPeerName flag via source-code grep. Setting "pinPeerName": true in both installs' ~/.hermes/honcho.json host blocks resolved it immediately.

Why this matters

For the documented "ambient thinking partner that follows you across devices" pattern that Hermes + Honcho enables, multi-instance is the default mode, not the edge case. Catching the user-peer split at setup time (or via clearer docs) would save real time and avoid the failure mode where the cross-instance bridge appears wired but is silently building two user models.