既有对话触发模型小时限额后无法实际切换到其他 API 或模型

**提交人**: Rigel
**客户端版本**: 0.1.66

---

## 现象

当一个既有对话中的订阅模型触发小时限额后，在该对话内切换到已配置的其他 API 提供商或模型，界面看似完成了切换，但后续请求仍无法正常执行。受影响的对话会表现为所有可选模型都不可用；新建对话则可以正常使用新的配置。

## 复现步骤

1. 在一个已有对话中使用订阅模型，直到触发小时限额。
2. 在同一对话内切换到另一个已配置的 API 提供商或模型。
3. 在该对话发送新的请求。

## 期望行为

切换后，后续请求应使用新选择的提供商和模型；即使原模型已限额，当前对话也应恢复可用。

## 实际行为

切换操作在界面层似乎生效，但当前对话未真正使用新的配置，仍处于不可用或自动重试状态。该对话内所有模型均无法使用。

## 复现频率

用户反馈：在既有对话触发小时限额后稳定出现。影响既有对话；新建对话可作为临时绕过方式并正常使用新配置。

## 已尝试

- 在受影响的对话内多次切换不同模型和已配置的自定义 API：无效。
- 新建对话：可恢复使用，说明配置本身可用。
---
**版本区域**: CN
**OS**: win32 x64 (10.0.19045)
**Harness**: Codex
**Model ID**: ` gpt-5.6-terra `
**界面语言**: zh-CN

No file, test, or entry point is identified in the issue. Reproduce the failure after an existing conversation reaches its hourly limit, then trace how that conversation stores the selected provider and model into subsequent requests. Done means switching within the existing conversation makes later requests use the new configuration, while new conversations continue to work.

Written by the indexing model from the issue text.