fix(channels): preserve Feishu clarification thread continuity

[zzp1221]

Fixes #3274

Summary

• 修复 Feishu 澄清卡片回复时 conversation/thread 丢失的问题。
• 回复澄清卡片时优先复用已有 root/parent/thread message id 映射。
• bot 发出的卡片 message id 会记录回同一个 DeerFlow thread。
• 补了 Feishu clarification card reply 的回归测试。

Test

• cd backend && uvx ruff check . --fix
• cd backend && uvx ruff format .
• cd backend && uvx ruff check .
• cd backend && uvx ruff format --check .
• git diff --check
• cd backend && uv run pytest tests/test_feishu_parser.py tests/test_channels.py::TestFeishuChannel -q
• cd frontend && pnpm test
• cd frontend && pnpm test:e2e

Note

The plain-message pending clarification state is intentionally in-memory and best-effort for the short 30-minute window. Explicit Feishu replies are still covered by persisted message-id mappings, so they continue to work across restarts.

Full backend suite was also run locally on Windows: 3611 passed, 31 skipped, 37 failed. The failures look unrelated to this Feishu change and are mostly Windows/local-env issues such as symlink privileges and path separator expectations.

[CLAassistant]

All committers have signed the CLA.

[Copilot]

Pull request overview

This PR fixes Feishu channel thread continuity when users reply to clarification cards, ensuring replies are routed back to the existing DeerFlow thread instead of starting a disconnected conversation.

Changes:

• Adds Feishu topic resolution using stored root/parent/thread message-id mappings.
• Records bot card message IDs back to the channel store for future reply lookup.
• Adds regression coverage for clarification card replies and running-card mapping persistence.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
backend/app/channels/feishu.py	Resolves Feishu topic IDs from stored mappings and remembers card/source metadata mappings during replies.
backend/tests/test_feishu_parser.py	Adds regression coverage for card replies using a stored parent message mapping.
backend/tests/test_channels.py	Extends Feishu running-card tests to verify source/card/root mappings are stored.

[zzp1221]

已补充修复：除了回复澄清卡片，现在也支持用户在群里直接发送澄清答复（例如选择编号或补充说明）时接回原 DeerFlow thread。

验证：

• uvx ruff check .
• uvx ruff format --check .
• git diff --check
• uv run pytest tests/test_feishu_parser.py tests/test_channels.py::TestFeishuChannel -q：23 passed
• uv run pytest tests/test_channels.py -q：104 passed
• 使用 deepseek-v4-flash 做了真实 API smoke 和本地 Feishu 链路验证：PASS
• 额外验证其他消息路径未受影响：PASS

[WillemJiang]

@zzp1221 , here are some comments for the code.

1. _pending_clarifications is in-memory only — lost on restart

The _pending_clarifications dict lives in process memory. If the Feishu channel restarts (deploy, crash, etc.) between the clarification card and the user's reply, the mapping is lost and the bug reappears.
This may be acceptable given the 30-minute TTL, but worth calling out in a comment or the PR description.

2. Key collision risk in _pending_key

def _pending_key(chat_id: str, user_id: str) -> str:
    return f"{chat_id}:{user_id}"

If the same user triggers two clarification cards in the same chat within the TTL, the second overwrites the first. The first clarification reply would then be treated as a new conversation. Consider whether _pending_clarifications should store a list or use a more specific key.

3. _has_current_turn_clarification heuristic is fragile

for msg in reversed(messages):
    if msg.get("type") == "human":
        break
    if msg.get("type") == "tool" and msg.get("name") == "ask_clarification":
        return True

This walks backward and stops at the first "human" message. If the agent calls ask_clarification followed by other tool calls (or nested agent turns with additional human messages), the heuristic could miss or incorrectly detect a clarification. Consider whether there's a more reliable signal from the graph execution.

[zzp1221]

@WillemJiang
Thanks for the review. I agree with these points and have addressed them.

For the in-memory pending state, this is intentional because it only covers the short-lived plain-message clarification reply path. Explicit Feishu replies are still handled by persisted message-id mappings. I’ve also called this out in the PR description.

Changes made:

• Pending clarification keys now use (chat_id, user_id) instead of a string key.
• Multiple pending clarifications for the same chat/user are queued and consumed FIFO, so later clarifications no longer overwrite earlier ones.
• Clarification detection now only marks pending when the current turn’s final effective message is ask_clarification, avoiding false positives from earlier messages in the same turn or previous turns.
• Added tests for multi-pending behavior, explicit reply priority, pending consumption, expiration, slash commands, and clarification detection.