fix(honcho): plug pinPeerName transition gaps

Three correctness gaps when honcho.json's identity-mapping config changes
mid-flight:

1. The gateway's agent cache signature ignored honcho identity keys, so
   editing peerName / pinPeerName / userPeerAliases / runtimePeerPrefix
   was silently dropped until an unrelated cache eviction. Extend
   _extract_cache_busting_config to fingerprint the resolved honcho
   config so the AIAgent rebuilds on the next message.

2. cmd_setup let single → multi flips orphan the pinned-pool history
   under peerName without warning. Detect the transition, warn that
   runtime users will resolve to fresh empty peers, and auto-steer to
   hybrid (alias the operator's runtime IDs back to peerName) so the
   operator's own continuity survives. yes / no overrides available.

3. README didn't document the orphaning behaviour. Add a "Migrating
   single → multi" callout under Deployment shapes.

Tests:
- TestPinTransition (test_pin_peer_name.py): fresh-manager flip resolves
  to runtime, in-process flip is gated by the per-key session cache
  (documents the gateway-cache-must-bust contract), 3 cache-bust
  signature tests for pin / aliases / prefix.
- TestProfilePeerUniqueness: two profiles pinned to distinct peerNames
  resolve to distinct peers; host-level peerName overrides root when
  pinned.
- test_single_to_multi_steers_to_hybrid_by_default and
  test_single_to_multi_yes_override_keeps_multi (test_cli.py): wizard
  guard end-to-end coverage.

plugins/memory/honcho/README.md

@@ -160,6 +160,8 @@ In gateway deployments (Telegram, Discord, Slack, etc.) each user arrives with a
 - **Multi-user gateway** — `pinUserPeer: false`, optional `runtimePeerPrefix`. Each runtime user → own peer. Recommended for bots serving many humans.
 - **Hybrid** — `pinUserPeer: false`, `userPeerAliases` mapping the operator's runtime IDs to `peerName`. Multi-user gateway where YOU are routed but others stay distinct.
 
+**Migrating single → multi.** Flipping `pinUserPeer` from `true` to `false` does not migrate data. Memory accumulated under `peerName` while pinned stays there; runtime users now resolve to fresh, empty peers. To preserve your own continuity, use the **hybrid** shape — alias your runtime IDs back to `peerName` so your turns keep landing on the pooled history while other users get their own peers. The setup wizard offers this path automatically when it detects a single → multi transition.
+
 ### Memory & Recall
 
 | Key | Type | Default | Description |

plugins/memory/honcho/cli.py

@@ -465,6 +465,25 @@ def cmd_setup(args) -> None:
     print("    skip   -- don't touch identity-mapping config")
     new_shape = _prompt("Deployment shape", default=current_shape).strip().lower()
 
+    # Transitioning single → multi orphans the peerName pool for runtime users
+    # (their resolved peers go from peerName to runtime-derived IDs with empty
+    # history).  Steer the operator toward hybrid so their own continuity is
+    # preserved via alias mappings.
+    if current_shape == "single" and new_shape == "multi":
+        peer_target = hermes_host.get("peerName") or current_peer or "user"
+        print(
+            f"\n  ⚠ Switching from single to multi will orphan memory accumulated\n"
+            f"    under peer '{peer_target}'.  Existing runtime users (Telegram,\n"
+            f"    Discord, etc.) will resolve to fresh, empty peers."
+        )
+        print("    To keep your own continuity, choose 'hybrid' and alias your\n"
+              "    runtime IDs back to peerName.")
+        confirm = _prompt("Continue with multi anyway? (yes/hybrid/no)", default="hybrid").strip().lower()
+        if confirm in {"hybrid", "h"}:
+            new_shape = "hybrid"
+        elif confirm not in {"yes", "y"}:
+            new_shape = "skip"
+
     if new_shape == "single":
         hermes_host["pinPeerName"] = True
         hermes_host.pop("userPeerAliases", None)