What does this PR do?

This PR makes the existing pinPeerName setting visible at the two places where users most need it: initial setup and status inspection.

The underlying pinPeerName fix already exists and solves a real multi-instance Honcho problem: a single human using Hermes across multiple front-ends can otherwise get split into multiple Honcho peers.

What is missing today is discoverability:

• hermes memory setup does not surface the setting when the user is configuring Honcho
• hermes honcho status does not show the effective value, which makes diagnosis harder when memory appears fragmented across devices

This change is intentionally a discoverability + diagnostics improvement around an already-correct runtime capability (no runtime identity rule changes, no default flips).

Solution Sketch

• introduce the smallest surface needed for the new capability in the touched subsystem
• preserve existing behavior and defaults outside the new entry point or configuration path
• cover the new path with focused validation before asking for review

Related Issue

Fixes #28283

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻️ Refactor (no behavior change)
• 🎯 New skill (bundled or hub)

Changes Made

• added a setup-wizard prompt that explains when pinPeerName should be enabled (plugins/memory/honcho/cli.py)
• persisted that choice into the active Honcho host config (plugins/memory/honcho/cli.py)
• surfaced the effective pinPeerName value in hermes honcho status (plugins/memory/honcho/cli.py)
• added regression coverage for the setup+status surface area (tests/honcho_plugin/test_cli.py)

How to Test

1. Run python -m pytest tests/honcho_plugin/test_cli.py -q -n 4.
2. Run hermes memory setup and confirm the prompt surfaces pinPeerName with a clear explanation.
3. Run hermes honcho status and confirm it prints the effective pinPeerName value.

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform:

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — or N/A
• I've updated cli-config.yaml.example if I added/changed config keys — or N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — or N/A
• I've updated tool descriptions/schemas if I changed tool behavior — or N/A

Screenshots / Logs

• N/A (CLI change). If needed, I can attach a hermes memory setup capture and a hermes honcho status output snippet.