notifications/claude/channel MCP notifications not injected as <channel> blocks (Telegram plugin)

Summary

When an MCP server sends notifications/claude/channel over a stdio transport, Claude Code receives it (the SDK call resolves successfully) but the <channel> block is never injected into the conversation.

Steps to Reproduce

1. Install the official Telegram plugin (telegram@claude-plugins-official v0.0.6)
2. Configure it with a valid bot token and an allowlisted user
3. Send a message from Telegram to the bot
4. Bot receives the message (ackReaction fires), calls mcp.notification({method: 'notifications/claude/channel', params: {...}}) — call resolves with no error
5. No <channel> block appears in the Claude Code conversation

Diagnostic Evidence

Added file-based logging to the plugin. After sending two Telegram messages:

[2026-05-22T07:26:00.552Z] inbound received, sending notification...
[2026-05-22T07:26:00.553Z] notification sent OK
[2026-05-22T07:26:59.112Z] inbound received, sending notification...
[2026-05-22T07:26:59.113Z] notification sent OK

Both calls resolved with no error. Neither produced a <channel> block in the conversation.

Environment

• Claude Code: 2.1.148
• OS: Windows 11 Enterprise 10.0.26200
• Plugin: telegram@claude-plugins-official v0.0.6
• Transport: stdio (StdioServerTransport from @modelcontextprotocol/sdk)

Expected Behavior

Each notifications/claude/channel notification should inject a <channel source="telegram" ...>TEXT</channel> block into the next conversation turn.

What Works vs. What Does Not

• Outbound tools (reply, react, edit_message) work correctly — client-initiated RPC calls over the same transport
• The bot receives Telegram messages and ackReaction fires
• The bug is that Claude Code does not surface inbound notifications/claude/channel notifications as <channel> blocks
• The MCP server declares experimental: {'claude/channel': {}} capability during initialization

Additional Context

This was intermittently working in an earlier session at v2.1.148 but has been consistently broken after session restarts, with no changes to the plugin between working and non-working states.