Telegram channel plugin silently drops inbound messages during long tool calls

Description

The official Telegram channel plugin (telegram@claude-plugins-official, v0.0.4) silently drops inbound messages when Claude Code is busy processing long-running tool calls.

Reproduction

1. Enable the Telegram plugin and pair a chat
2. Start a task that involves extended tool calls (e.g. writing a large file via Bash, ~30–60 seconds)
3. Send a message from Telegram while the tool call is executing
4. Message never appears in the Claude Code conversation — it's silently lost

In my session, messages stopped arriving entirely after processing two ~14,000-word YouTube transcripts (heavy Bash + Write tool usage). Sending replies from Claude to Telegram continued to work. Subsequent messages from both iOS and macOS Telegram clients were not delivered to the conversation.

Root Cause (from reading server.ts)

The plugin delivers inbound messages via mcp.notification() over stdio (line 925 of server.ts). If this call fails — e.g. because the stdio pipe is congested during a long tool call — the error is caught and logged to stderr, but the message is permanently lost:

mcp.notification({
  method: 'notifications/claude/channel',
  params: { content: text, meta: { ... } },
}).catch(err => {
  process.stderr.write(`telegram channel: failed to deliver inbound to Claude: ${err}\n`)
})

Meanwhile, grammY's polling loop has already acknowledged the update to Telegram's Bot API (via the offset parameter in getUpdates), so Telegram won't re-send the message.

There is no message queue, retry logic, or fallback inbox for failed deliveries.

Expected Behaviour

Failed mcp.notification() calls should be retried, or messages should be queued to disk (the plugin already defines an INBOX_DIR at ~/.claude/channels/telegram/inbox/) and re-attempted when the pipe is available.

Environment

• macOS 15.4 (Darwin 25.4.0), Apple Silicon
• Claude Code with Telegram plugin telegram@claude-plugins-official v0.0.4
• grammY bot library with long-polling
• Messages lost from both iOS and macOS Telegram clients

Suggested Fix

1. On mcp.notification() failure, write the message payload to INBOX_DIR as a JSON file
2. On successful delivery of any subsequent message (or periodically), check INBOX_DIR for queued messages and re-attempt delivery
3. Alternatively, implement a small retry loop with backoff before giving up

This would make the channel resilient to transient stdio congestion without requiring architectural changes.