Telegram plugin: no message cache or reply_to_message context surfacing

Problem

The Telegram plugin has two limitations that affect message reliability and conversational context:

1. No local message cache

The plugin receives messages via getUpdates but doesn't store them locally. When a Claude session is busy (e.g., running a long tool call), incoming messages can be received by the plugin's polling loop but never delivered to the conversation. Once getUpdates advances the offset past those messages, they're gone — there's no local record to recover from.

This is especially painful in practice: if a user sends several messages while Claude is mid-tool-call, some or all of them can be silently dropped with no way to retrieve them natively through the plugin.

2. No reply_to_message context

When a Telegram user replies to (quotes) a previous message, the Bot API includes reply_to_message in the Update object containing the full original message (text, sender, timestamp, message_id). The plugin's handleInbound function constructs the channel notification metadata but omits this field entirely.

This means Claude cannot see what message the user is quoting when they use Telegram's reply feature, losing important conversational context. The user might say "yes do this" in reply to a specific earlier message, and Claude has no idea what "this" refers to.

Proposed improvements

1. Local message log: Add a lightweight append-only JSONL file that records every inbound message as it arrives from getUpdates, before any delivery to the conversation. This provides a durable local record so missed messages can be recovered without hitting the Telegram API. The log could be rotated or capped by size to avoid unbounded growth.

1. Surface reply_to_message: Include reply_to_message data (at minimum: text, from.first_name, message_id, date) in the channel notification metadata so Claude can see quoted context when a user replies to a previous message.

1. get_message MCP tool: Consider adding an MCP tool that retrieves a message from the local log by message_id, so Claude (or a skill) can look up earlier messages on demand.

Current workaround

Using the Telegram Bot API's forwardMessage to forward a missed message (by ID) back into the chat, reading it, and then deleting the forwarded copy. This works but is fragile and user-visible — the forwarded message briefly appears in the chat before deletion.

Environment

• Claude Code CLI with Telegram plugin (v0.0.4)
• Telegram Bot API polling via getUpdates