telegram: permission-reply acknowledgement uses reactions Telegram rejects; outbound path still MarkdownV2/4096 on Bot API 10.3

Two separable things: one small confirmed defect, and the outbound feature gap it sits in.

## Defect: the permission acknowledgement reaction can never appear

`server.ts` acknowledges a permission reply by reacting with ✅ or ❌:

```ts
const emoji = permMatch[1]!.toLowerCase().startsWith('y') ? '✅' : '❌'
void bot.api.setMessageReaction(chat_id, msgId, [{ type: 'emoji', emoji }]).catch(() => {})
```

Neither is on Telegram's fixed reaction whitelist. `ReactionTypeEmoji` in the Bot API reference lists 73 emoji; ✅ and ❌ are not among them, so the call is rejected and the `.catch(() => {})` swallows it. The user answers a permission prompt and gets no visible acknowledgement at all — and because the failure is silent, nothing indicates why.

`ACCESS.md` already documents this constraint for `ackReaction` ("Telegram accepts only a fixed whitelist ... anything else is silently ignored"), so the rule is known in the plugin; the permission path just predates or missed it.

👍/👎 are on the whitelist and carry the same meaning.

Worth noting for anyone verifying this: probing `setMessageReaction` against a non-existent `message_id` does **not** distinguish valid from invalid emoji — Telegram checks message existence first and returns `400: message to react not found` for whitelisted and non-whitelisted emoji alike. The whitelist in the API reference is the thing to check against.

## Gap: the outbound path predates Bot API 10.x

The plugin pins `grammy@^1.21.0` (resolving to 1.41.1 / `@grammyjs/types@3.25.0`), which is roughly Bot API 9.x. Consequences on the sending side:

- **Escaping.** `reply` offers `format: 'markdownv2'` and tells the caller "Caller must escape special chars per MarkdownV2 rules". An assistant writes Markdown natively, and MarkdownV2 requires every `.` `-` `(` `!` to be backslash-escaped, so this is a standing source of mangled replies. Bot API 10.1 rich messages take ordinary Markdown with no escaping.
- **Length.** Replies chunk at 4096. Rich messages allow 32768, which turns most answers from three or four fragments into one message. Splitting also currently cuts without regard to fenced code blocks, so a split mid-fence leaves an unterminated ``` in one part and an orphan closer in the next.
- **Progress.** A long task is silent until it completes. `sendMessageDraft` / `sendRichMessageDraft` (10.1) give an animated placeholder and a stop button, with the press arriving as the `stopped_message_generation` update.
- **Interaction.** There is no way to offer a choice as buttons, so every reply requires typing — the dominant cost when the client is a phone.
- **Threading.** The tool description tells the assistant to omit `reply_to` for ordinary answers, so replies arrive unthreaded. In a chat where a second message can arrive while the first is still being answered, they also pair up wrongly.

## Ready branch

External PRs auto-close here, so: longpoll/claude-plugins-official@`telegram-rich-messages-and-streaming` (004b95d5), if useful.

It bumps grammy to 1.46 (`@grammyjs/types` 5.0.0, Bot API 10.3) and covers the above: `format: 'rich'` with Markdown-aware splitting that repairs fences across a cut, a `draft` tool plus a server-side refresh so the stop button always exists, status reactions on the inbound message, a `buttons` array with action/copy/url types, and inbound/answer pairing via a FIFO so quote-replies land on the message actually being answered. Also the ✅/❌ fix above, and the `message:rich_message` handler discussed in #5724.

95 assertions via `bun run test` in the plugin directory, no added dependencies. Behaviour changes are each behind an `access.json` key and default-on; the defaults are the debatable part and easy to flip.

Environment: plugin `telegram@claude-plugins-official` 0.0.7, bun 1.2.2, macOS 26.6.2.