fix: 修复 Grok 中转站空结果并增强规划与抓取容错

[Boulea7]

概要

这个 PR 是对现有 #35 的后续替代版，保持最小改动原则，主要吸收了：

• #35 的 planning 顺序/会话错误加固
• #35 / #37 的输出污染清洗方向
• #34 的 provider completion 解析修复思路

这次没有引入新工具、没有修改公开 schema、没有提交 README / 测试 / 本地协作文件，只提交核心代码修复。

主要改动

1. 修复 web_search 在部分 Grok 中转站上的空结果/截断/假成功问题

• 将 Grok provider 调整为 非流式 completion 优先，并保留 SSE 文本 fallback
• 放宽 completion / SSE 的安全兼容解析路径
• 新增对“空占位 completion 帧（choices=null）”的显式识别
• 不再把上游异常吞成空字符串，而是返回可诊断错误文本
• 尽量在错误信息中保留 request_id 和错误摘要，便于和中转站排障

2. 加固 plan_* 调用稳定性

• 增加 phase 前置顺序校验
• 增加 level=1/2 完成态拦截
• 缺失 session_id 时返回结构化错误，而不是模糊失败
• 保持现有 6 个 plan_* 工具设计不变，不恢复单一 search_planning

3. 清理 web_search 输出污染，并增强 web_fetch 错误显性化

• 过滤 <think> 和明显的拒绝/注入类污染前缀
• 兼容 I'm Grok ... I don't follow/adopt ... 这类新污染前缀
• web_fetch 对 Tavily / Firecrawl 失败给出更明确的 provider 级错误归因
• 区分 307/401/403、登录页/认证页、空内容、provider 连续失败等场景

4. Windows 兼容性

• 在 Windows 下显式设置 WindowsSelectorEventLoopPolicy()
• 避免 stdio/MCP 链路在 Windows 上卡死

为什么要这样改

最近的真实问题不是简单的“默认模型设置不对”，而是不同 Grok 中转站对 /v1/chat/completions 的实现质量差异很大。

本地实测中：

• https://api.925214.xyz/v1
  • grok-4.1-fast：0/6 成功
  • grok-4.20-beta：0/6 成功
  • 均返回空占位帧：choices=null
• https://ai.huan666.de/v1
  • grok-4.1-fast：10/10 成功，且输出干净
  • grok-4.20-beta：成功率高，但更慢，且历史样本里出现过一次污染前缀

因此这次 PR 优先修的是：

• 不要再把真实上游问题吞成空结果
• 让解析链路兼容更多安全变体
• 让维护者能够直接拿错误文本和 request_id 去找中转站排障

验证

本地自动化验证

• uv run --with pytest --with pytest-asyncio pytest -q
  • 通过：20 passed
• uv run --with ruff ruff check .
  • 通过
• python3 -m py_compile src/grok_search/*.py src/grok_search/providers/*.py tests/*.py
  • 通过
• git diff --check
  • 通过

本地未提交的回归覆盖点

以下回归测试已在本地跑过，但本次按最小改动原则 未把 tests 一并提交：

• provider 使用 stream=False 发请求
• 标准 JSON completion 解析
• SSE 文本 fallback 解析
• 空占位 completion 帧识别
• 登录页 HTML / 307 跳转错误显性化
• planning 缺失 session / phase 越序 / level 完成态拦截
• <think> 与拒绝/注入污染文本清洗
• Windows WindowsSelectorEventLoopPolicy() helper
• web_fetch provider 级错误聚合

有意不包含的内容

为保持 PR 聚焦，这次 没有 一并提交：

• README / 文档修正
• 测试目录
• AGENTS.md
• .gitignore
• 本机 MCP 配置切换

这些内容都已在本地验证或整理，但不属于这次上游代码修复的最小必要集合。

关联

• 相关 PR：#34 #35 #37
• 相关 issue：#33 #39