MCP channel notifications dropped when Claude is busy (stdin/stdout pipe blocked)

Bug Description

Telegram channel plugin notifications (notifications/claude/channel) are silently dropped when Claude Code is busy processing a tool call or generating output. The MCP stdin/stdout pipe appears to block, causing the first inbound message to be lost. The second message arrives normally because Claude has returned to idle state by then.

Steps to Reproduce

1. Start Claude Code with --channels plugin:telegram@claude-plugins-official
2. Trigger a long-running tool call (e.g., a slow Bash command, large file read, or Agent subagent)
3. While Claude is processing, send a Telegram message
4. Observe: the message never appears in the conversation
5. Send a second message after ~5-10 seconds
6. The second message arrives normally

Expected Behavior

All inbound channel notifications should be delivered reliably, even when Claude is busy processing. Messages should be queued and delivered when the model returns to idle.

Actual Behavior

The first message after a busy period is silently lost. The mcp.notification() call in the plugin succeeds (no error thrown), but the notification never reaches Claude's conversation context. This suggests the MCP transport layer (stdio) has no backpressure handling — writes to stdout succeed but the consumer isn't reading.

Environment

• Claude Code v2.1.81
• macOS (Darwin 25.2.0)
• Telegram plugin from claude-plugins-official
• grammy bot framework for Telegram polling

Impact

This makes the Telegram channel unreliable for real-time communication. Users learn to "send twice" as a workaround, which is a poor UX. The issue likely affects ALL MCP channel plugins, not just Telegram.

Suggested Fix

The MCP SDK's notification delivery should either:

1. Queue notifications and deliver them when the consumer is ready (backpressure)
2. Return an error/promise rejection when delivery fails so plugins can implement retry logic
3. Provide a notification_ack mechanism so plugins know the message was received

Currently mcp.notification() is fire-and-forget with no delivery guarantee.