feat: AI 重新命名的不可用态与跨供应商起名策略

## 使用场景 / Use case

「用 AI 重新命名」✨ 按钮在当前供应商不支持标题生成时，用户只能点击后才得到提示。更友好的体验是：不可用时就置灰，并就近说明原因；或者允许用另一家已连接的供应商给这条会话起名。

## 当前问题 / Current limitation

#2063 已经把「点击后」的失败提示分档（空任务 / 供应商不支持 / 通用失败），但有两件被明确推迟的产品决策还没定：

1. **不可用态**：当前供应商不支持标题生成时，✨ 按钮是否置灰？何时置灰（渲染期探测凭证/wire 可用性 vs 点击后反馈）？置灰会改变现有入口可用性，需要在「提前告知用户」与「增加一次渲染期探测成本」之间权衡。
2. **跨供应商起名**：是否允许用**另一家**已连接的供应商给当前会话起名？这会改变模型与数据/凭证外发边界（prompt 发给非会话所属的供应商），是产品 + 安全决策，不是实现细节。

`dash-s-cindy` 在 #2071 的确认分析里明确点了这两件：「不要在本次确认中把『供应商不支持』改成按钮禁用，也不要自动切换到其他供应商……需要单独产品决策」。

## 期望方案 / Proposed solution

需要产品侧决策（实现细节随后）：

- 不可用态：选 A) 维持点击后提示（现状）/ B) 渲染期探测并置灰 + tooltip 说明 / C) 其它。
- 跨供应商起名：选 A) 不允许，始终只用会话所属供应商（现状，对应 #2097 的 C3 契约）/ B) 允许，但明确外发边界（发给哪家、是否记 usage、凭证来源）/ C) 其它。

注：在标题通道收敛到通用路由（见 #2097）之后，「不支持的供应商」会变得极少（只剩无可路由 wire 的极端配置），本 issue 的紧迫性会下降。建议先做收敛，再议本 issue。

## 已考虑的替代方案 / Alternatives considered

- 在 #2063 / 收敛 PR 里一并做：被明确拒绝，因为会混入未确认的产品决策，拖慢 bugfix 合并。

---

关联：#2046、#2063、#2071、#2097。不阻塞 #2046 系列，等产品决策。

Start by reading the decisions and context in #2097, #2071, and #2063, especially the existing provider-support behavior and routing contract. The issue is done when product decisions are recorded for unavailable states and cross-provider naming, with implementation scope and follow-up work clearly defined.

Written by the indexing model from the issue text.