IM: 除 Telegram 外的渠道尚未接入交互失效收口

## 问题

#1711 让交互被作废时把卡片收口成失效态，但收口动作挂在 adapter 的**可选**能力位 `interactionExpiredNotice` 上，**目前只有 Telegram 配了**。其余渠道走 `if (!notice) return` 早退，卡片照旧留在会话里，按钮看着能点、实际已经没人认。

这是 #1711 有意的保守选择（其它渠道的 `updateInteractiveCard` 语义没有实测过，不想把未验证的面塞进一个在跑 review 的 PR），不是遗漏。现在补齐。

## 各渠道现状

| 渠道 | adapter 是否接了 | 文案是否现成 |
|---|---|---|
| telegram | ✅ 已接 | ✅ `telegram/uiText.ts` |
| discord | ❌ 未接 | ✅ **文案已存在**：`discord/uiText.ts:13` 的 `expiredCardNotice` |
| feishu | ❌ 未接 | ❌ 需新增 |
| dingtalk | ❌ 未接 | ❌ 需新增 |
| wechat | ❌ 未接 | ❌ 需新增 |
| wecom | ❌ 未接 | ❌ 需新增 |

**Discord 是最省事的一个** —— 文案早就写好了，只差 adapter 里加一行 `interactionExpiredNotice: discordUiText.expiredCardNotice`。建议从它开始。

## 每个渠道要验的东西

不能无脑接上就完事，各渠道的卡片更新语义不同，接之前逐个确认「用 `buildResolvedCard`（空 buttons）去 update 时，按钮是否真的消失」：

- **discord**：components 数组，需确认空数组是否清空按钮行
- **feishu**：卡片 JSON 整体替换，需确认 elements 结构
- **dingtalk**：同上，另需确认交互卡的更新接口是否有额外限制
- **wechat / wecom**：这两个是 `chunked-text` 类渠道（无富卡片），`dropInteractionCard` 里 `richIm == null` 会直接跳过 —— **需要先确认它们是否真的没有可收口的卡片形态**，如果有文本形态的确认提示，收口方式要另设计

## 影响

修好之前：Telegram 之外的渠道，交互被作废时卡片不会有任何变化，用户对着死按钮反复点，没有任何反馈。

## 验收标准

1. 逐个渠道接上失效文案，且**每接一个都实测过**「作废后按钮确实消失」
2. `chunked-text` 渠道（wechat / wecom）单独判断：确认没有卡片形态，或给出文本形态的收口方案
3. 每个渠道的改动带回归测试
4. 可以拆成多个小 PR 逐个渠道走，不必一次全接（每个渠道的验证面是独立的）

## 关联

- #1711 引入 `interactionExpiredNotice` 能力位与 Telegram 的接线