[Bug] OpenAI 兼容层对 Gemini 模型的 Tools (Function Calling) 转换支持不完整

[happypatwu]

例行检查

我已确认目前没有类似 issue

我已确认我已升级到最新版本

我已完整查看过项目 README，尤其是常见问题部分

我理解并愿意跟进此 issue，协助测试和提供反馈

我理解并认可上述内容，并理解项目维护者精力有限，不遵循规则的 issue 可能会被无视或直接关闭

问题描述

one-hub 的 OpenAI 兼容层在处理 Gemini 模型的 tools/function-calling 时，转换链路不完整，导致带有 tools 的请求无法正常工作（例如配合 OpenClaw 等现代客户端时）。

具体表现在以下两点：

输入 Schema 转换问题（未过滤 strict 字段）：
当把 OpenAI 格式的工具 schema 翻译成 Gemini 的 function_declarations 时，兼容层未能剥离或忽略 OpenAI 的 strict 字段，导致向 Gemini 上游发送请求时直接报错：Unknown name "strict" at function_declarations。

输出响应映射问题（未正确转换 functionCall）：
当 Gemini 返回包含工具调用的 Native 响应时（最底层文本在 candidates[].content.parts[].text，工具调用在 parts[].functionCall / functionResponse），one-hub 未能将其正确映射回 OpenAI 标准的 tool_calls 和内容格式。导致上层客户端（如 OpenClaw）拿不到可消费的输出，表现为“空输出”。

综上，普通文本请求（不带 tools）可以正常回复，但在 tools 模式下，兼容层存在字段未过滤和回写映射不完整的问题。

复现步骤

配置 one-hub 代理 Gemini 模型，并使用 OpenAI 兼容接口（/v1/chat/completions）进行调用。

发起不带 tools 的普通对话请求（成功返回）。

发起带有 OpenAI 格式 tools schema（且包含 strict 参数）的请求。

观察报错，会收到类似 Unknown name "strict" at function_declarations 的错误。

（若绕过 strict 报错）发送合法的 function-calling 触发请求，观察 one-hub 的回包，发现未能将 Gemini 的 parts[].functionCall 等字段正确转义为 OpenAI 兼容的 tool_calls 结构。

预期结果

针对 Gemini 模型的 OpenAI 兼容层需要补齐针对 tools 的支持：

Schema 转换：在处理 OpenAI -> Gemini function_declarations 转换时，主动丢弃/过滤掉 strict 等不兼容的参数，避免上游报错。

响应回写：正确解析 Gemini Native 的回包字段（candidates[].content.parts[].text、parts[].functionCall、`parts