[Bug][Discord 远程接管] 飞书与 Discord 接管同一会话后模型误判 Discord 未连接

## 现象

同时配置飞书和 Discord 机器人，并先后通过两个渠道接管同一个桌面会话后，从 Discord 发送普通消息，模型回复“目前未连接可用的 Discord 通道或机器人，请先配置 Discord 集成或提供 webhook”。

桌面端此时明确显示会话正由 Discord 远程接管，Discord 入站与自动回复链路实际可用。

验证环境：Windows 已安装版 Cindy，2026-07-21 现场复现 1/1。

## 复现步骤

1. 打开“设置 → IM 机器人 → 个人”，分别连接飞书机器人和 Discord Bot。
2. 从飞书私聊机器人，接管一个桌面会话并发送“测试飞书”。
3. 从 Discord 私聊 Bot，接管同一个桌面会话。
4. 确认桌面端显示当前会话正由 Discord 远程接管。
5. 在 Discord 中发送“测试discord”。
6. 查看 Bot 回复和桌面会话状态。

## 期望行为

系统应识别本轮消息来自 Discord 接管渠道。模型生成普通回复后，由现有 Discord adapter 自动回传，不应要求用户重新配置 Discord、机器人或 webhook。

飞书和 Discord 同时关联同一会话时，界面展示、消息路由及最终回复渠道应保持一致。

## 实际行为

模型将普通 Discord 入站消息误判为主动调用 Discord 外发工具的请求，并回复当前没有可用 Discord 通道。

Discord 实际接管链路没有断开，错误回复来自模型对当前渠道和回复方式的错误判断。

## 源码分析

- Discord 入站消息通过 `bindingStore` 路由到目标桌面 session，回复由 Discord adapter 的 `sendMarkdownText` 和流式回复链路自动发送。
- 接管已有 desktop session 时，`turnRunner` 构造的 `UserMessage` 只有用户文本，没有当前来源渠道标记。
- MCP provider 注册了飞书外发能力，但没有 Discord 对等发送工具。模型能看到飞书工具，却不知道当前 Discord 回复会由接管链路自动发送。
- 多渠道可同时指向同一 session，但内存反向索引只保留最后一个 identity，存在界面当前渠道与实际绑定关系不一致的风险。
- makecindy/cindy#56 只跟踪 CindyAI 品牌旧文案，#201 处理登出后的 IM 生命周期，均不覆盖本问题。

## 验收标准

- [ ] Discord 接管会话收到普通文本时，不会误判为主动调用 Discord 外发工具。
- [ ] 在 Discord 中发送“测试discord”可获得正常回复，并由 Discord adapter 回传。
- [ ] 飞书接管及飞书主动外发能力不受影响。
- [ ] 飞书与 Discord 同时接管同一 session 时，界面渠道、入站路由和回复归属一致。
- [ ] 多渠道绑定、解绑、反向索引和 interaction listener 有回归测试覆盖。
- [ ] Windows 和 macOS 均完成双渠道接管回归。

Trace the bindingStore route into the desktop session and inspect how turnRunner constructs UserMessage for an existing takeover. Read the Discord adapter’s sendMarkdownText and streaming reply paths, then examine the reverse index and interaction listener behavior for multiple bindings. Done means Discord replies use the active takeover channel, Feishu behavior remains intact, and regression coverage verifies binding, unbinding, routing, and reply ownership.

Written by the indexing model from the issue text.