fix: 为 Codex 增加 Responses 工具兼容性

[sandleft]

改动

在 src/handlers/responses.js 中补充了对 Codex Responses API 工具类型的兼容处理，修复代理此前直接拒绝部分工具定义的问题。

这次兼容/转换的工具类型包括：

• custom
• namespace
• web_search
• tool_search

此外，这次改动还保留了 namespace 相关的工具命名信息，使 Codex 的本地工具调用可以通过这个 OpenAI 兼容代理正确映射，而不是在请求解析阶段直接失败。

为什么

较新的 Codex 默认使用 Responses API，请求里可能会带一些不属于传统 OpenAI function tool 形态的工具定义。

在这个改动之前，WindsurfAPI 会直接报错，例如：

• Unsupported Responses tool type: custom
• Unsupported Responses tool type: web_search
• Unsupported Responses tool type: namespace
• Unsupported Responses tool type: tool_search

这会导致 codex / codex exec 虽然已经正确连到了代理，但仍然无法在真实本地项目工作流中使用。

这个 PR 的目标，是让 WindsurfAPI 能作为 Codex Responses 客户端的兼容层正常工作，而不需要修改 Codex 本体。

测试

本次为手动验证。

1. 语法检查

执行了：

node --check src/handlers/responses.js

2. Docker 重建与重启
使用 Docker Compose 基于本地修改重新 build 并启动服务
重启后确认 /health 返回正常
3. Codex 本地目录验证
在真实本地工作目录下通过代理运行 Codex，验证其不再因为 Responses 工具类型不兼容而在启动/执行时失败。

示例命令：

codex exec --skip-git-repo-check -C "C:\Users\user\Documents\python" -s read-only "现在是什么目录？只回答当前工作目录路径。"
验证结果：

Codex 返回了预期的本地工作目录

4. 回归验证
确认代理不再被以下 Responses 工具类型阻塞：
-custom
-web_search
-namespace
-tool_search

[dwgx]

多谢 @sandleft 推到这条边界，Codex Responses 的 tool 路径以前没人压过。

读完一遍发现一个会让 custom / web_search / namespace 回转识别失效的点：

• handleResponses() 当前把 body.tools 传给 chatToResponse / ResponsesStreamTranslator
• 但 namespace / custom / web_search 的 metadata 是挂在 flattened chatBody.tools 上（带 __response_tool 标记）
• 这导致回转那一步拿不到原 Responses tool 的 type，落到默认 function 分支

另外 namespace 直接拼接，如果两个 namespace 下有同名 tool 会撞，建议加个分隔符或者拼之前先 dedupe。

286 行改动 + 0 测试也是合并卡点。能再补一轮 metadata 透传修复 + Responses native tool 的最小测试用例吗？格式跟 test/responses.test.js 现有那几条对齐就行。补完直接 squash 进去。

PR 留 open 等你这一版。