[BUG] QwenPaw feishu session: queue consumer stays alive & stuck -> session silently unresponsive; new messages can't spawn a new consumer

## 🐛 [BUG] QwenPaw 飞书会话：单个 session 的 queue consumer 长驻卡死后该会话静默无响应，同一 session 新消息无法新建消费者

## 现象 / Symptom

一个飞书**私聊（DM）会话**运行数小时后突然"静默卡死"：

1. 该会话某条消息进入**高优先级（priority=10，卡片类）** 处理路径后，consumer **不再返回拉取下一条**、也不崩溃（无 Traceback），queue 永远不空。
2. 之后（同一 session）**普通消息（priority=20）到达**，日志有 `feishu recv`（确实收到），但**连 `Created queue` 都没有打印** —— 新消息既未建新 consumer 也未入队，被静默丢弃。
3. 该 session 从此**永久无响应**；**其他飞书会话（群聊）完全正常**（能创建/消费队列）——问题隔离在单个 session。
4. 无任何异常日志，属**静默卡死**。

## 环境
- QwenPaw 通道层 `UnifiedQueueManager`（`unified_queue_manager.py`）
- 运行期间 `omniroute` MCP 客户端**持续反复发生 `Session terminated`**（08-31~09-03 每天数十次），疑似诱因（见下）。

## 关键日志证据

会话：`channel=feishu`，`session=5ff775cf`（DM），`chat_id=96831736-26f9-4946-b003-dbdf7a06c83d`

| 时间 (UTC+8) | 日志 | 说明 |
|---|---|---|
| 08:23:59 | `Created queue: feishu 5ff775cf priority=10` | 高优先级 consumer 创建，处理卡片类消息 |
| 08:56:13 | `_consume_with_tracker: ... 5ff775cf` | 该 session 最后一次正常消费 |
| 08:56 ~ 18:01 | （近 9 小时）**全无此 session 任何 consume/新 queue/清理** | 卡死窗口 |
| 13:11:54 | `feishu recv ... 5=5ff775cf msg_id=om_x...a45742` | **收到普通消息，且未打印 `Created queue`，永久不处理** |
| 18:01:13 | 服务重启 shutdown | — |
| 18:01:13 | `Consumer stopped: 5=5ff775cf priority=10`（`unified_queue_manager.py:268`） | **08:23 建的 p10 consumer 长驻存活约 10 小时直到进程退出** |
| 18:01:13 | `Cleaned up idle queue: 5=9cce_07aeace8` | idle 清理机制本身正常在跑（清除的是另一普通空队列） |
| 18:01:13 | `Message ignored (task already running): 5=5ff775cf`（`base.py:586`，`This should not happen`) | 卡死的 task 状态残留 |
| 18:04 | 重建 queue + Consumer started → 恢复正常 | 重启即恢复 |

## 根因分析（推断，需官方确认）

`channels/unified_queue_manager.py`:
- `_run_consumer()`：**仅 `finally` 块 `pop(queue)`**。consumer 卡在一条消息（长时间 await，如 MCP 断连/重连不响应取消）时永不达 `finally`，queue 键残留在 `_queues`。
- `_cleanup_idle_queues()`：**仅清理 `queue.empty()` 的队列**。卡死的 consumer 让队列"不空/在用"，idle 清理永不接管 → consumer 长驻存活（本 case 实测约 10 小时）。
- **同一 session 新消息（不同 priority）**：`enqueue()` 的 key=(channel,session,priority)。p20 于从未建过，理论上应 `Created queue`；实测 13:11:30 未打 → 疑似在 enqueue 前置环节（如 `_extract_session_id` / 已存在活跃 consumer 的复用逻辑）被**静默 drop**，需要官方复现确认。

`channels/manager.py::_consume_queue()`：**单条消息处理无超时/强制退出**，一条消息可无限阻塞。

## 期望 / Suggested fix
1. 给 consumer 单条消息处理加**超时硬杀**：超时仍未结束 → 强制终止 task 并从 `_queues` 移除，后续消息可重建。
2. `_cleanup_idle_queues()` 增加兜底：对"队列既有但 consumer 已长期无进展/无 consumer"的残留键强制移除（不只 `queue.empty()`）。
3. `_get_or_create_queue()`：当既有 queue 的 consumer 已死但键残留时自动替换，确保新消息总能新建/复用有效 queue。
4. 排查 `feishu recv` 后未打印 `Created queue` 的静默丢弃路径。

## 附
- 诱因旁证：`omniroute` MCP `Session terminated` 在该窗口内持续发生（每天几十次），consumer 极可能 await 在重连逻辑上。
- 相关：#7483（cron+share_session 卡死 running 状态，机制相似但场景不同，普通 session 也应有相同保护）。