官方 Telegram bot：终稿编辑撞 flood 后答案静默丢失，缺重发兜底（改动在服务端仓）

> **改动落在服务端仓 `xindong/cindy-server`**（`telegram-hook-server`），本仓不需要改代码。
> 在这里开是为了统一入口，接手时直接照下面的定位过去改。

## 问题

官方 Telegram bot 的长轮次答案，在终稿编辑撞上 Telegram flood 限制后会**静默丢失**。

过程区会对**同一条消息**持续 `editMessageText`（一轮几十到上百次），而携带最终答案的那一次编辑排在整轮**最后**，最容易被限流挡下。挡下之后没有任何补救 —— 那一轮的答案就没了，用户只看到过程区停在最后一次成功的编辑上。

## 要改哪里（服务端仓 `xindong/cindy-server`）

- `telegram-hook-server/src/telegram/client.ts` —— `call()` 在 429 时按 `retry_after` 退避重试，撞满 `maxAttempts` 直接抛错，**抛完就没了**
- `telegram-hook-server/src/telegram/client.ts` —— `editAdaptiveMessage` 虽有 fallback 链，但只做**格式降级**（rich markdown → HTML → 纯文本），对 flood 无效
- `telegram-hook-server/src/telegram/controller.ts` —— 终稿编辑的调用点

## 客户端已有对照实现，可直接照搬

个人 Telegram bot（BYO token，客户端直连）在 #1636 修过同一个问题，已合并：

```
编辑失败 → 重发一条新消息（携带完整答案） → 删掉旧的那条
```

实现见本仓 `packages/lizi-im/src/telegram/streamingText.ts` 的 `finalizeInPlaceOrRepost`，测试见同目录 `__tests__`。官方 bot 缺的就是这一环。

## 服务端已有零件，不用从零写

- `telegram/client.ts` 的 `deleteMessage(chatId, messageId)` —— 已存在
- `telegram/controller.ts` 的 turn reopen 路径已经在用「删旧 + 重发」的组合（`staleRoutes` 循环里调 `deleteMessage`）

差别只在触发时机：现有的删旧发新由**客户端主动发起的 reopen** 触发，这里需要的是**编辑失败时自动兜底**。

## 影响

用户让 bot 干一件耗时较长的活，**最终答案不会出现**。轮次越长越容易命中（编辑次数随时长线性增长）。用户看不出发生了什么，只知道 bot 没给结果。

## 验收标准

1. 终稿编辑因 429 / flood 失败且重试耗尽时，改为发一条新消息承载完整答案，并删掉旧的那条
2. 新消息发送也失败时，抛回**原始的编辑错误**，不要用重发的错误盖掉真实原因
3. 删旧失败（权限不足 / 已被删）不影响已送达的答案，吞掉即可
4. 回归测试：模拟 `editMessageText` 持续 429，断言最终产生一条新消息且旧消息被删

## 关联

- #1636 个人 bot 的同一问题（已合并，实现与测试可直接参照）
- #1728 官方 bot 私聊确认卡不回传群聊（另一个问题，同样落在 `telegram-hook-server`）