Follow-up to commit 0a87dec5 (PR #2461, merged before live verification).
Two corrections to the docstring on `_build_initialize_result()`:
1. The original "mirrors molecule-mcp-claude-channel server.ts:374"
claim is wrong on two axes. Line 374 is unrelated poll-init code
(a comment inside `registerAsPoll`). The actual capability site
is server.ts:475, where the bun bridge declares only
`{ capabilities: { tools: {} } }` — *no* `experimental.claude/channel`.
The bun bridge is reported to deliver `notifications/claude/channel`
successfully in Claude Code despite this, which is direct counter-
evidence that adding the capability was the bug fix.
2. The `@modelcontextprotocol/sdk` server's `assertNotificationCapability`
does not include `notifications/claude/channel` in any of its switch
cases, meaning custom (non-spec) notification methods are sent
regardless of declared capabilities. Server-side, the declaration
is almost certainly a no-op.
This commit doesn't remove the capability — additive, not destructive,
and the new tests pin its presence — but downgrades the docstring's
certainty so the next person debugging "channel notification didn't
fire" doesn't trust a stale claim and pursues the more likely root
causes:
- writer.drain() swallowing exceptions on a closed pipe
- inbox-thread → asyncio.run_coroutine_threadsafe race during init
- MCP transport not yet attached when the first inbox event fires
Live verification per #2444 §2 (fresh Claude Code session on this wheel
with a peer A2A message, observe whether the interrupt fires) remains
the open hard-gate.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
63ef3b128c