Bug: v2.4.x search_feeds 稳定 60s 超时 (context deadline exceeded)，不带 filters 也复现；同环境 list_feeds 正常

问题描述

search_feeds 稳定失败，无论是否带 filters，均在约 60s 后返回：

工具 search_feeds 执行时发生内部错误: context deadline exceeded

同一部署、同一时刻，list_feeds（首页推荐流）完全正常、约 5s 秒回，说明服务本身、登录态、网络均正常，问题隔离在 search_feeds 单个接口。

复现步骤

1. initialize 建立 MCP 会话（streamable-http）。

2. 直接调用 search_feeds，仅传 keyword，不带任何 filters：

   {"name":"search_feeds","arguments":{"keyword":"新冠"}}

3. 约 60s 后返回 context deadline exceeded。

4. 换关键词（如"阳了"）复测，结果一致。

实测对比（同一 SID、同一时刻）

接口	参数	结果	耗时
list_feeds	无	✅ 正常返回 35 条	~5s
search_feeds	keyword=新冠（无 filters）	❌ context deadline exceeded	~61s
search_feeds	keyword=阳了（无 filters）	❌ context deadline exceeded	~61s

已排除的因素

• 不是 filters 触发：完全不传 filters 仍然超时（区别于 #801 的"带筛选条件失败"）。
• 不是调用方式：initialize 后第一发直接 search、中间不插任何其他调用，同样超时；串行/并行结果一致。
• 不是登录/网络/服务：同环境 list_feeds 5s 正常。
• 不是版本回退能解决：从最新版降级到历史版本，search_feeds 仍稳定 60s 超时；仅在极早的一次冷启动偶发成功过一次。

现象特征

失败表现为"无声挂死到超时"，与 #812 描述的 go-rod MustXxx / MustWaitStable 默认无限期等待、元素不出现时不报错、最终吃满 60s 超时的机制吻合。

结合 #801（v2.4.3 search_feeds 筛选面板 DOM 回归），怀疑小红书近期改动了搜索结果页 / 筛选面板的 DOM 结构，导致 search_feeds 在页面元素定位阶段（即便不展开筛选面板，也可能在等待搜索结果容器）无限等待到 context 超时。

建议：

• 给 search_feeds 链路上的 MustWaitStable / MustElement 等加显式超时，让失败点暴露为明确报错而非 60s 无声超时（便于用户提供有效日志）；
• 复核当前小红书搜索结果页 DOM，确认结果容器 / 筛选面板选择器是否已失配。

环境

• 版本：v2.4.x（最新版复现，降级历史版本同样复现）
• 接入方式：streamable-http MCP（本地 localhost:18060）
• 部署：macOS 本机
• 登录状态：正常（check_login_status 显示已登录）

相关 issue：#801 #812