- cli-config.yaml.example: Hub platform config section and MCP server example
- website/docs/user-guide/messaging/hub.md: full setup guide with registration,
  config options (env vars + config.yaml), MCP meta-tool, and reference table

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Move hub.md from position 14 (conflicts with wecom.md) to position 15.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

websockets v15 renamed the connect API. The old websockets.client.connect()
is deprecated. Also disable library-level pings — the gateway blocks the
event loop during agent processing, causing ping timeouts after 20s.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Without this entry, _get_platform_tools crashes with KeyError: 'hub'
when a Hub message arrives because the platform registry has no hub key.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Hub migrated from admin.slate.ceo/oc/brain to hub.slate.ceo.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Hub is an agent-to-agent messaging platform: every inbound message
triggers a fresh LLM call on the receiving agent. The gateway was
forwarding five kinds of internal traffic over that wire, each of
which made the partner agent respond and trigger another LLM call:

1. status_callback — rate-limit notices, retry/fallback events
   (~6 messages per failed request, 34 emit sites in run_agent.py)
2. "Operation interrupted: ..." strings returned as final_response
   when the agent is interrupted mid-call
3. "API call failed after N retries: ..." strings returned as
   final_response when retries are exhausted
4. interim_assistant_callback — mid-turn commentary
5. stream consumer sending a partial + continuation pair because
   HubAdapter never declared SUPPORTS_MESSAGE_EDITING=False

Under rate-limit pressure paths 1+2+3 compound into an unbounded
feedback loop between paired agents (status → interrupt → failure
string → LLM call → status).

This commit:

- Gates status_callback and interim_assistant_callback on
  source.platform != Platform.HUB, mirroring the existing
  Platform.WEBHOOK exclusion pattern for tool_progress.
- Filters known internal error/interrupt prefixes in
  HubAdapter.send() as a belt-and-suspenders guard for any future
  path that sends final_response over Hub.
- Declares SUPPORTS_MESSAGE_EDITING = False on HubAdapter so the
  gateway stream consumer skips streaming entirely for Hub, sending
  one final message per turn instead of two.

Adds 4 unit tests covering the suppression filter and the
no-editing flag. No new test failures from full gateway suite
(pre-existing 14 failures are unrelated env issues).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Hub's inbound → LLM call → auto-reply architecture has no surface for the
LLM to express "this message doesn't warrant a response." The model's
text output IS the reply — producing zero tokens is the only silence
path, and RLHF-trained models essentially never do that. Tars tried to
signal intent by writing "[No response.]" which of course became a real
Hub message the peer then answered. Result: stable 10-second
"Holding." / "Silent." oscillations between agents with nothing left to
say, even after the earlier Honcho / status-suppression fixes.

Port openclaw's NO_REPLY convention (see openclaw
auto-reply/tokens.ts + auto-reply/reply/normalize-reply.ts):

- HubAdapter.send() drops an exact-match NO_REPLY before hitting the
  wire. Mixed content with a trailing NO_REPLY has the token stripped;
  if nothing substantive remains (just whitespace or markdown-emphasis
  chars like `**`) the send is suppressed too.
- build_session_context_prompt() teaches the agent the convention via
  Platform.HUB-specific guidance — when to emit NO_REPLY, the strict
  formatting rules, and concrete use cases (acks, notifications already
  processed, status pings with nothing to add).

The decision stays with the LLM and is visible in its trajectory. No
pre-filter, no architectural rewrite. Telegram / Discord / other
platforms are untouched — they still reply-by-default because humans
expect an answer.

Adds 4 tests: exact-match, mixed-strips-to-empty, trailing-strip-delivers,
prose-mention-passes-through.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The busy-ack message ("⚡ Interrupting current task, I'll respond
shortly") is UX reassurance for a human recipient waiting on their
agent. For an agent peer on Hub, it's just unsolicited semantic
content they try to interpret, which we observed fueling false
"message injection" narratives across the fleet.

Add a WANTS_BUSY_ACK class attribute (default True for back-compat)
and set it to False on HubAdapter. The interrupt + pending-message
queue still run — only the outbound ⚡ message is suppressed when
the recipient is another agent.

Test: tests/gateway/test_busy_session_ack.py ::
test_suppresses_ack_when_adapter_opts_out — verifies no ack, but
interrupt + queue still happen.