pref(provider):优化provider架构

[phantom5099]

变更说明

本次重构优化provider模块架构，主要解决以下问题：

1. 架构冗余：多个provider实现重复代码，且部分provider使用OpenAI兼容协议无需独立实现
2. 并发安全：runtime直接访问配置可能导致TOCTOU竞态条件
3. 代码重复：模型检查逻辑在多处重复实现

通过配置集中化、删除冗余实现、修复并发安全，提升代码质量和系统稳定性。

---

主要改动

1. Provider配置集中管理

新增文件：internal/config/builtin_providers.go

改动内容：

• 将OpenAI、Gemini、OpenLL的配置常量统一迁移到config包
• 定义provider名称、BaseURL、默认模型、API Key环境变量等常量
• 提供统一的DefaultProviders()函数返回所有内置provider配置

影响范围：

• internal/provider/builtin/builtin.go：改用config.DefaultProviders()
• 删除gemini、openll包中的BuiltinConfig()函数

---

2. 删除冗余Provider实现

删除文件：

• internal/provider/gemini/gemini.go (31行)
• internal/provider/gemini/gemini_test.go (31行)
• internal/provider/openll/openll.go (30行)
• internal/provider/openll/openll_test.go (43行)

删除原因：

• Gemini和OpenLL均使用OpenAI兼容协议
• 无需独立实现，通过配置即可使用OpenAI driver
• 减少维护成本，避免重复代码

---

3. 修复Runtime并发安全问题

改动文件：internal/runtime/runtime.go:123

改动前：

resp, err := modelProvider.Chat(ctx, provider.ChatRequest{
    Model:        cfg.CurrentModel,  // ⚠️ 直接访问配置，可能竞态
    // ...
})

改动后：

resp, err := modelProvider.Chat(ctx, provider.ChatRequest{
    Model:        resolvedProvider.Model,  // ✅ 使用快照，避免竞态
    // ...
})

解决问题：

• 使用ResolvedSelectedProvider()返回的快照
• 避免在请求过程中配置被并发修改
• 确保整个请求周期内配置一致性

---

4. 消除重复代码

改动文件：internal/provider/service.go

删除函数：

// 删除重复实现
func containsModel(models []string, modelID string) bool {
    target := normalizeKey(modelID)
    for _, model := range models {
        if normalizeKey(model) == target {
            return true
        }
    }
    return false
}

改用统一实现：

// 改用config包的统一实现
config.ContainsModelID(selected.SupportedModels(), modelID)

影响函数：

• SetCurrentModel (service.go:113)
• selectModel (service.go:136)

---

5. 其他优化

builtin包简化：

• 移除对gemini和openll包的导入
• 简化默认配置构建逻辑

测试更新：

• 删除gemini和openll测试文件
• 更新其他测试以适配架构变更

---

预期收益

代码质量提升

• ✅ 消除重复逻辑：统一模型检查，提升一致性
• ✅ 职责更清晰：配置管理与实现分离，符合单一职责原则

系统稳定性增强

• ✅ 修复并发安全：避免TOCTOU竞态条件
• ✅ 配置一致性：runtime使用快照机制，确保请求周期内配置稳定

架构设计优化

• ✅ 配置集中化：provider配置统一在config包管理
• ✅ 协议复用：OpenAI兼容协议的provider无需独立实现
• ✅ 易于扩展：新增OpenAI兼容provider只需添加配置

---

测试验证

单元测试

测试文件：

• internal/provider/registry_test.go - 10个测试函数
• internal/provider/builtin/builtin_test.go - 1个测试函数
• internal/provider/openai/openai_test.go - 9个测试函数

关键测试场景：

测试项	测试函数	状态
Provider切换	TestServiceSelectProviderAndSetCurrentModel	✅ 通过
Driver不支持	TestServiceSelectProviderRejectsUnsupportedDriver	✅ 通过
模型列表	TestServiceListProvidersUsesConfiguredMetadata	✅ 通过
流式响应	TestProviderChatConsumesSSEAndMergesToolCalls	✅ 通过
错误处理	TestProviderChatHTTPErrorResponses	✅ 通过

集成测试

主链路验证：

用户输入 -> TUI -> Runtime -> Provider Service -> OpenAI Driver -> API

验证项：

• ✅ Provider切换正常
• ✅ Model切换正常
• ✅ 消息发送正常
• ✅ 会话持久化正常

回归测试

执行命令：

go test ./internal/provider/... -v
go test ./internal/runtime/... -v

测试结果：

• ✅ 所有单元测试通过
• ✅ 集成测试通过
• ✅ 无破坏性变更

---

风险评估

低风险

• 删除的provider（gemini、openll）未在生产环境使用
• 并发修复不影响单线程场景
• 配置迁移向后兼容

Fixes #94

[codecov]

Codecov Report

❌ Patch coverage is 95.12195% with 2 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
internal/config/model.go	75.00%	0 Missing and 1 partial ⚠️
internal/provider/openai/openai.go	0.00%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!

[minorcell]

@phantom5099

PR body 目前没有抓住重点。reviewer 首先需要知道的是：

1. 这次主改动是什么；
2. provider 的配置权是交给用户还是程序内建；
3. 后续新增 provider 的标准做法是什么。

请先把这 3 点写清楚，再写收益、测试和风险。否则信息很多，但决策不清晰。