Feature Request: 支持 Gemini CLI 请求格式接入

[Jiabinone]

现状

README 里已经提到 ccNexus 支持 Claude、OpenAI、Gemini 格式互转，添加端点时也可以选择 claude/openai/gemini/openai2 转换器。

但目前看起来还不能直接承接 Gemini CLI 的请求格式，所以 Gemini CLI 还不能像 Claude Code、Codex CLI 一样，直接挂到 ccNexus 上做统一代理。

诉求

希望增加对 Gemini CLI 请求格式的支持，让 ccNexus 可以作为 Gemini CLI 的代理后端使用。

期望行为

1. 支持 Gemini CLI 发出的请求路径、请求头和流式响应格式。
2. 最好新增一个明确的转换器类型，比如 gemini-cli，或者在现有 gemini 转换器上兼容 Gemini CLI。
3. 支持 Gemini CLI 常见的 API Key 接入场景，尽量减少额外适配成本。
4. 如果可行，希望补一份最小配置示例，说明如何把 Gemini CLI 指向 ccNexus。

使用场景

• 把 Claude Code、Codex CLI、Gemini CLI 统一接到 ccNexus
• 复用现有的端点轮换、故障切换、统计能力
• 降低多 CLI、多模型环境下的配置复杂度

价值

如果支持 Gemini CLI，ccNexus 就可以进一步成为统一的 CLI 网关入口。对于同时使用多个 AI CLI 工具的用户，这个能力会比较实用。

感谢考虑。

[Jiabinone]

补充一个技术细节，方便评估这个需求的可行性：

Gemini CLI 官方仓库里已经明确保留了自定义网关入口。

• 在 google-gemini/gemini-cli 的 packages/cli/src/utils/sandbox.ts 里，会透传 GOOGLE_GEMINI_BASE_URL 和 GOOGLE_VERTEX_BASE_URL
• 这说明 Gemini CLI 走代理 / 自定义 base URL 不是旁门用法，而是官方代码已经考虑到的接入方式

另外，ccNexus 当前仓库里已经有现成的 Gemini 转换链路：

• internal/transformer/cx/chat/gemini.go
• internal/transformer/cx/responses/gemini.go

所以如果后续支持 Gemini CLI，感觉可以优先从最小闭环开始：

1. 先兼容 Gemini CLI 的请求路径 / 请求头 / 流式返回
2. 内部复用现有 Gemini 转换逻辑，或者单独加一个轻量的 gemini-cli 适配器
3. 先覆盖最常见的文本对话与流式输出场景

这样用户就能把多个 CLI（Claude Code / Codex CLI / Gemini CLI）统一接到 ccNexus，复用轮换、统计、鉴权这些能力。