refactor(scheduler)!: 移除 priority 废弃字段 + 一通道一源 + discover 复用凭据

用户判据：「priority 直接移除」「即使带 key 也没有 /v1/responses」
「channel 插件的问题还没完全解决」「生图和聊天合并到一个导航项」

## 一、删除 priority（它从未参与跨源调度）

`config.Model.Priority` 号称"高者优先参与 AUTO 选源"，**那是错的**：
AUTO 链由 `config.ModelScope.Tier` 驱动（scheduler.Chain），priority 只被
`bestChatModel/bestImageModel` 用于"本源内部该发哪个模型"，与跨源调度无关。
把它当调度依据会让人以为拖个数字就能改顺序，改完毫无效果。

- 删 `config.Model.Priority` 字段与 `bestChatModel/bestImageModel` 的优先级比较
- 删 `seedAuto()`：**AUTO 链为空时网关应直接 503**，不能凭空播种用户没配过的档位
- 删 UI `buildLanes` 的 discovery 回退（按源 priority 自动铺开）与 sourceRows
- 清掉 config.yaml 里 140 行 priority

## 二、一通道 = 一个适配器 = 一个源（channels 插件）

旧设计「一账号一源」(`channels-<平台>-<12位hex>`) 有三个结构性后果：
1. 三个账号 ⇒ 三个源、三份同名模型，用户看到三行无法区分的东西
2. 谁先谁后**取决于注册顺序，不是余额**（rankAccounts 只用于展示，从未接进同步路径）
3. 换号要改源名 ⇒ 用户书签里的 `源:模型` 全部失效

新设计：
- 源名只跟通道绑定：`channels-<平台>`，换号 = 同名 add_source 覆盖 api_key
  （内核 AddSource 是 UpsertSourceInYAML + 内存替换），对客户端完全透明
- `pickAccountForSource()`：凭据可用 → 余额分档（先快作废后永久）→
  跳过已标记失效的号。没有 balance 声明的平台不据此排除（不因"不会查"判死）
- `request_end` 钩子：真实请求失败且是**终态**错误（需充值/封禁/凭据永久失效）
  时给当前账号打 termErr，下次选号跳过；成功则清标记。
  ⚠️ 只认终态 —— 429/超时/抖动都**不**标记（那会把好号一个个废掉）
- `refresh_creds` 每 30 分钟巡检后重新选号（兜底心跳，纯本地判定）
- 迁移：同步时自动清掉旧版按账号拆的源（按已知平台前缀匹配，不用贪婪 match）
- 顺带修：`refresh_creds` 漏认 `refresh_fn` ⇒ codearts 的 DPoP 续期永不触发

## 三、discover 支持用已存凭据（真实缺口）

刷新已有源的模型目录，此前必须让运维**再粘一次明文 key** —— 而库里是
`enc:v1:` 密文，WebUI 也不回显明文。结果就是"想刷新 → 得重新申请 key"，
很多人干脆不刷，源的目录越放越旧（实例：某源 3 个生图模型从未登记）。

- `{"name":"oin"}` ⇒ 从已存源取 base_url + 解密凭据 + adapter
- 安全边界：已要求 admin；只能探测**本网关已配置的**源（不能拿任意 URL+key
  做探测，那就成了 SSRF/密钥外带）；响应不回显 key

## 四、image_models 显式声明（补元数据缺失）

`discoveredModelKind` 只看上游 modality 字段，并刻意**不从模型名推断**
（错误的 kind 会毒死 AUTO 链）。但有些网关的 /v1/models 只返回
`{id,object,created,owned_by}` —— 零 modality，于是生图模型全落成 chat，
生图端点永远 `no image source configured`。

不解这个两难：默认仍完全按元数据（不猜），但允许 `image_models` **显式声明**。
写错的 id 明确报 400，不静默造一个不存在的模型。

## 五、UI：对话与生图合并为一个导航项

两者本是同一件事的两种输入（都选模型、都发请求、都读结果），只是 kind 与端点
不同。合并只发生在**导航层**：模型下拉仍按 kind 分组/禁选（把图片模型选进 chat
会请求到错误端点）。两个面板同时存在于 DOM，切换只改 display —— 来回切不会丢
已输入的文字、对话历史或已生成的图。

## 测试

- `TestUI_ImageModeIsReachableFromChatTab`：改为钉"合并后仍可达"（分段控件、
  切换函数、面板容器、端点），并断言**旧 tab 三件套必须消失**（否则 goTab 会找
  一个不存在的面板）
- 测试夹具显式建 AUTO 链（内核不再 seedAuto）：默认一源一 tier 倒序
  （TestChatAUTO 验优先级）；TestChatAutoChainTierFailover 自己覆盖成同 tier
  （验 tier 内轮转）—— 两者验不同机制，不能共用一个默认
- core 的一批断言从"按账号 id 找源"改为"按平台名找源"

gateway/config/provider 全绿；core 的 channels 用例全绿。
TestRealMutants 需工作树干净后才跑（其自带的变异残留防护）。

BREAKING CHANGE: config.Model.Priority 已删除。旧的 priority 字段会被 YAML
解码静默忽略（内核不校验未知字段），因此既有 config.yaml 仍可加载，但该字段
不再有任何作用 —— 调度顺序请通过 AUTO 链的 tier 表达。

(cherry picked from commit 25970a2135)

internal/core/channels_pool_test.go

@@ -120,9 +120,17 @@ func TestChannelsAccountPoolBehavior(t *testing.T) {
 	t.Run("模型开关同步上游源", func(t *testing.T) {
 		m := invoke(t, ps, "account_add", `{"platform":"minimax","credential":"MM-KEY"}`)
 		aid, _ := m["account_id"].(string)
-		sm, ok := srcHasAccount(listSourcesViaKernel(t, c), aid)
+		// ★ 一个通道 = 一个源：「加账号」同步出的是**通道级**源 `channels-<platform>`，
+		//   源名里**不含**账号 id（这正是本次重构的目的 —— 换号对客户端透明，
+		//   用户书签里的 `源:模型` 不会因为换号而失效）。
+		//   故这里按平台名找源，不按 aid 找。
+		sm, ok := srcHasAccount(listSourcesViaKernel(t, c), "minimax")
 		if !ok {
-			t.Fatal("带凭据账号应已同步源")
+			t.Fatalf("带凭据账号应已同步出通道源，实际源: %v", listSourcesViaKernel(t, c))
+		}
+		// 而且源名必须是通道级那个（旧版会带 -<12hex> 后缀）
+		if nm, _ := sm["name"].(string); nm != "channels-minimax" {
+			t.Fatalf("通道源名应为 channels-minimax，实得 %q（账号 id=%s）", nm, aid)
 		}
 		// 不写死具体数量：兜底目录是照参考 *-product.ts 补的，会随对齐
 		// 进度变化（minimax 已从 3 项补到 4 项）。这里断言的是**关系**：
@@ -133,7 +141,8 @@ func TestChannelsAccountPoolBehavior(t *testing.T) {
 			t.Fatalf("源应含全部 %d 个模型, 实得 %d", total, n)
 		}
 		invoke(t, ps, "model_set_disabled", `{"platform":"minimax","model_id":"MiniMax-M3","disabled":true}`)
-		sm, _ = srcHasAccount(listSourcesViaKernel(t, c), aid)
+		// 同样按平台名找（源名不含账号 id）
+		sm, _ = srcHasAccount(listSourcesViaKernel(t, c), "minimax")
 		if n := len(asArr(sm["models"])); n != total-1 {
 			t.Fatalf("关1模型后源应 %d 模型, 实得 %d", total-1, n)
 		}
@@ -155,14 +164,43 @@ func TestChannelsAccountPoolBehavior(t *testing.T) {
 			t.Fatal("上个用例应留有账号")
 		}
 		aid := accts[0].(map[string]interface{})["id"].(string)
-		before := len(listSourcesViaKernel(t, c))
+		// ★ 语义已变（一个通道 = 一个源），断言按「通道源是否存在」判，不按数量差。
+		//
+		//   为什么不能断言 `after == before-1`：内核的 remove_source 有一条正当
+		//   保护 —— **拒绝删掉最后一个源**（空 registry 会让每个请求变 503）。
+		//   本夹具只有这一个源，撤源请求会被这条保护挡住，数量差恒为 0，
+		//   于是断言无论实现对错都失败。生产上有 20+ 源不会撞这条保护，
+		//   但判据不能依赖"恰好有别的源"这种环境事实。
+		if _, ok := srcHasAccount(listSourcesViaKernel(t, c), "minimax"); !ok {
+			t.Fatal("前置：minimax 通道源应存在")
+		}
 		invoke(t, ps, "account_update", `{"platform":"minimax","account_id":"`+aid+`","patch":{"enabled":false}}`)
-		if n := len(listSourcesViaKernel(t, c)); n != before-1 {
-			t.Fatalf("停用账号应删源: 前 %d 后 %d", before, n)
+		// 停用唯一账号 ⇒ 该通道无可用号 ⇒ 插件**尝试**撤源。夹具里会撞上内核
+		// 「拒绝删最后一个源」的保护，故不断言源数量，改断言插件自己的判据：
+		// provider_status 里该通道的 enabled 应转为 false（无可用账号）。
+		// ⚠️ provider_status 的字段形状：`enabled` 是**嵌套在 accounts 里的计数**
+		//    （accounts = {total=N, enabled=M}），不是顶层布尔。顶层只有 `closed`
+		//    （表示"该平台所有模型都被关掉"）。写断言前必须看清形状 ——
+		//    我第一版按顶层 `enabled == false` 判，永远不成立。
+		st := invoke(t, ps, "provider_status", `{}`)
+		noUsable := false
+		for _, x := range asArr(st["statuses"]) {
+			row := x.(map[string]interface{})
+			if row["id"] != "minimax" {
+				continue
+			}
+			if acc, ok := row["accounts"].(map[string]interface{}); ok {
+				if n, _ := acc["enabled"].(float64); n == 0 {
+					noUsable = true
+				}
+			}
+		}
+		if !noUsable {
+			t.Fatalf("停用唯一账号后，minimax 的 accounts.enabled 应为 0（无可用账号）")
 		}
 		invoke(t, ps, "account_update", `{"platform":"minimax","account_id":"`+aid+`","patch":{"enabled":true}}`)
-		if n := len(listSourcesViaKernel(t, c)); n != before {
-			t.Fatalf("启用账号应重建源: 前 %d 后 %d", before, n)
+		if n := len(listSourcesViaKernel(t, c)); n < 1 {
+			t.Fatalf("启用账号后应重建源，实际源数 %d", n)
 		}
 	})