fix(channels): 账号顺序的确定性 + reorder 真正改内核源顺序

## ① 真实缺陷：同秒创建的账号，顺序**不确定**
`poolList` 的排序键是 `priority` 降序 + `createdAt` **升序**，而 `createdAt` 是
**秒级**（`os.time()`）⇒ 同一秒建的两个账号比较**相等** ⇒ 相等时 `table.sort`
的结果取决于 `pairs()` 遍历顺序 —— **不确定**。
实测：按 a,b,c 顺序建三个账号，`poolList` 回的是 `[a,c,b]`。

后果不只是"顺序看着乱"：**源注册顺序 = poolList 顺序 = 内核尝试顺序**
⇒ 同秒创建的账号里"先试哪个"是随机的（buddy 15 天窗口下影响先用谁的积分），
且可能每次进程重启都变。修法：加 **id 作稳定兜底键**（唯一且不变）。

## ② reorder 只改字段、不影响路由
`account_reorder` 只设 `acct.priority`，**不重注册源**。而一个源一旦注册，
顺序就固定了 ⇒ 重排对实际路由**毫无影响**（"优先账号"并不会先被试）。
修法：重排后按新顺序**整体重放一遍** `syncAccountSource`
（remove+add 会把源移到最后，故必须整体重放，只补被移动的那几个相对顺序仍不对）。

## 判据（2 条 + 变异 2/2）
internal/core/channels_reorder_effect_test.go
- reorder 必须真的改变**内核 list_sources 的顺序**（判据看内核里的真实顺序，
  不是 pool 里的 priority 字段）
- 同优先级 + 同秒创建时，顺序必须由**稳定键**(id)决定（字典序）

★ 两个判据第一版**都不咬变异**，原因各异，值得记下：
1. reorder 判据：初始顺序恰好**已是**目标顺序 ⇒ 无法区分"重排生效"与"本来就对"。
   改法：显式断言初始顺序、并让目标顺序与之**相反**。
2. 确定性判据：我直接断言 `account_add` 之后的顺序，而 `account_add` 是
   **直接同步自己那一个账号**（源顺序 = add 顺序），**走不到排序逻辑** ⇒
   测的其实是 add 顺序。另外**多轮 in-process 反复构造也测不出** ——
   `pairs()` 顺序在同一次进程里是稳定的，只有跨进程/跨分配才变。
   改法：走**批量重注册**路径（`__resync_sources_probe`）+ 显式把 priority 拉平
   构造"排序键完全相同"的场景，再断言字典序。

## 顺带修的判据自身问题
- `sourceOrder` 原来顺带调了 `__sync_source_probe`（内部 remove+add）⇒
  **"测之前先动了被测对象"**，顺序忽而两个忽而一个。改为**只读**。
- 探针取内核返回时按 `{sources:[...]}` 取，而 `actionListSources` 返回的是
  **裸数组** ⇒ 恒得空列表。
- 夹具漏授 `add_source` 内核权限 ⇒ 源一个都不出现（内核会明确拒绝，只是我
  没看返回值）。子测试才能拿到独立的 env 与目录（同函数内 `t.Setenv` 只生效一次）。

internal/lua/plugins/channels.lua

@@ -52,7 +52,7 @@ plugin.kernel = { "add_source", "list_sources", "probe_all", "reset_health", "st
 
 -- WebUI 可调用的导出函数（POST /api/plugins/channels/call/{fn}）。
 -- set_endpoints 让运维把渠道端点指向自建代理/镜像；测试用它打假上游。
-plugin.exports = { "set_endpoints", "account_add", "account_list", "account_update", "account_clear_credentialless", "account_delete", "account_test", "account_refresh", "account_reorder", "account_reset", "account_retest", "account_adopt", "model_list", "model_refresh", "model_set_disabled", "model_set_disabled_many", "model_set_all_disabled", "model_clear_dead", "provider_status", "provider_set_enabled", "provider_get_order", "provider_set_order", "credits_claim_all", "credits_status", "credits_balances", "credits_pool_reason", "credits_permanent_lock", "backup_export", "backup_import", "backup_status", "auto_checkin", "gateway_get_enabled", "gateway_set_enabled", "usage_token_ledger", "usage_badge", "usage_badge_preference", "onboarding_status", "onboarding_claim", "__trae_derive_probe", "__codearts_sign_probe", "__qoder_machine_probe", "__qoder_refresh_probe", "__codearts_dpop_probe", "__codearts_cred_probe", "__codearts_adapter_sign_probe", "__sync_source_probe", "__trae_solo_probe", "__adapter_install_probe", "__store_dir_probe", "__set_loopback_probe", "reap_loopbacks", "__zcode_diag_probe", "__trae_entry_probe", "__is_model_gone_probe", "__rank_accounts_probe", "__inject_refresh_platform_probe", "__clear_capabilities_probe", "__qoder_claim_outcome_probe", "__is_free_probe", "__claim_covers_probe", "__schedule_probe", "__parse_capability_probe", "__inject_capability_probe", "__ttl_reset_probe", "__ttl_probe", "__ttl_invalidate_probe", "__serial_probe", "__serial_release_probe", "__set_legacy_cred_probe", "__read_cred_probe", "__clear_all_creds_probe", "credits_tier_probe", "__set_lock_permanent_probe", "__set_expiring_window_probe", "__expiring_window_probe", "__record_dead_probe", "__catalog_gate_probe", "__catalog_gate_fail_probe", "credits_capability", "claims_capable" }
+plugin.exports = { "set_endpoints", "account_add", "account_list", "account_update", "account_clear_credentialless", "account_delete", "account_test", "account_refresh", "account_reorder", "account_reset", "account_retest", "account_adopt", "model_list", "model_refresh", "model_set_disabled", "model_set_disabled_many", "model_set_all_disabled", "model_clear_dead", "provider_status", "provider_set_enabled", "provider_get_order", "provider_set_order", "credits_claim_all", "credits_status", "credits_balances", "credits_pool_reason", "credits_permanent_lock", "backup_export", "backup_import", "backup_status", "auto_checkin", "gateway_get_enabled", "gateway_set_enabled", "usage_token_ledger", "usage_badge", "usage_badge_preference", "onboarding_status", "onboarding_claim", "__trae_derive_probe", "__codearts_sign_probe", "__qoder_machine_probe", "__qoder_refresh_probe", "__codearts_dpop_probe", "__codearts_cred_probe", "__codearts_adapter_sign_probe", "__sync_source_probe", "__trae_solo_probe", "__adapter_install_probe", "__store_dir_probe", "__set_loopback_probe", "reap_loopbacks", "__zcode_diag_probe", "__trae_entry_probe", "__list_sources_probe", "__clear_priorities_probe", "__resync_sources_probe", "__is_model_gone_probe", "__rank_accounts_probe", "__inject_refresh_platform_probe", "__clear_capabilities_probe", "__qoder_claim_outcome_probe", "__is_free_probe", "__claim_covers_probe", "__schedule_probe", "__parse_capability_probe", "__inject_capability_probe", "__ttl_reset_probe", "__ttl_probe", "__ttl_invalidate_probe", "__serial_probe", "__serial_release_probe", "__set_legacy_cred_probe", "__read_cred_probe", "__clear_all_creds_probe", "credits_tier_probe", "__set_lock_permanent_probe", "__set_expiring_window_probe", "__expiring_window_probe", "__record_dead_probe", "__catalog_gate_probe", "__catalog_gate_fail_probe", "credits_capability", "claims_capable" }
 
 
 
@@ -2741,7 +2741,15 @@ local function poolList(provider)
   table.sort(out, function(x, y)
     local px, py = x.priority or 0, y.priority or 0
     if px ~= py then return px > py end -- priority 大者优先（参考 reorder 语义）
-    return (x.createdAt or 0) < (y.createdAt or 0)
+    local cx, cy = x.createdAt or 0, y.createdAt or 0
+    if cx ~= cy then return cx < cy end
+    -- ★ 必须给**确定性**兜底：createdAt 是**秒级**，同一秒建的两个账号比较相等，
+    -- 而相等时 table.sort 的结果取决于 pairs() 的遍历顺序 —— **不确定**
+    -- （实测：按 a,b,c 顺序建的三个账号，poolList 回的是 [a,c,b]）。
+    -- 后果不只是"顺序看着乱"：源注册顺序 = poolList 顺序 = 内核尝试顺序，
+    -- 故同秒创建的账号里"先试哪个"是随机的，且可能每次进程重启都变。
+    -- 用 id 作最后的稳定键（id 唯一且不变），让顺序完全确定。
+    return tostring(x.id or "") < tostring(y.id or "")
   end)
   return out
 end
@@ -7007,7 +7015,22 @@ function plugin.account_reorder(req)
     local acct = poolGet(plat.id, tostring(aid))
     if acct then acct.priority = #ordered - i + 1 poolAdd(plat.id, acct) end
   end
-  return { status = 200, json = { ok = true } }
+  -- ★ 必须**重注册源**，否则重排不生效。
+  --
+  -- 链路：poolList 按 priority 降序 → syncAccountSource 的调用顺序 → 内核里源的
+  -- **注册顺序** → 内核按 candidates 顺序依次尝试。而一个源**一旦注册，顺序就固定**
+  -- 了（改动 pool 记录不影响它）。故重排后必须按新顺序 remove+add 一遍，
+  -- 让"优先账号"真的排在前面。
+  --
+  -- 真实收益（buddy 15 天窗口）：不重排的话，快到期积分不会被优先消耗 ⇒
+  -- **白白过期**（参考为此有 rankBuddyAccountsByBalance）。
+  -- ⚠ remove+add 会把源移到注册队列末尾，所以**必须整体按新顺序重放一遍** ——
+  --   只重注册被移动的那几个会让它们的相对顺序取决于调用顺序，而不是最终顺序。
+  for _, a in ipairs(poolList(plat.id)) do
+    syncAccountSource(plat.id, a.id)
+  end
+  return { status = 200, json = { ok = true,
+    reordered = #poolList(plat.id), applied_to_sources = true } }
 end
 
 -- ============================================================================
@@ -11238,6 +11261,54 @@ function plugin.claims_capable(args)
   } }
 end
 
+-- plugin.__clear_priorities_probe：只给测试用 —— 把所有账号的 priority 拉平。
+-- 用于构造"排序键完全相同"的场景（同优先级 + 同秒 createdAt），
+-- 检验排序是否有确定性兜底。
+function plugin.__clear_priorities_probe(args)
+  args = args or {}
+  local plat = platformById(args.platform)
+  if not plat then return { json = { error = "未知平台" } } end
+  local n = 0
+  for _, a in ipairs(poolList(plat.id)) do
+    a.priority = nil
+    poolAdd(plat.id, a)
+    n = n + 1
+  end
+  return { json = { ok = true, n = n } }
+end
+
+-- plugin.__resync_sources_probe：只给测试用 —— 按 poolList 顺序批量重注册源。
+-- 「排序是否有确定性兜底」必须在**批量重注册**路径上验：account_add 是直接同步
+-- 自己那一个（源顺序 = add 顺序），走不到排序逻辑。
+function plugin.__resync_sources_probe(args)
+  args = args or {}
+  local plat = platformById(args.platform)
+  if not plat then return { json = { error = "未知平台" } } end
+  local n = 0
+  for _, a in ipairs(poolList(plat.id)) do
+    syncAccountSource(plat.id, a.id)
+    n = n + 1
+  end
+  return { json = { ok = true, n = n } }
+end
+
+-- plugin.__list_sources_probe：只给测试/诊断用 —— 内核里当前登记的源**及其顺序**。
+-- 顺序就是内核实际尝试的顺序（candidates 按注册序），故“重排是否生效”必须看它，
+-- 而不是看 pool 里的 priority 字段（改了字段不代表路由变了）。
+function plugin.__list_sources_probe()
+  local ls = __llmsproxy_kernel.call("list_sources", {})
+  -- ⚠ 内核 actionListSources 返回的是**裸数组**（不是 {sources:[...]}）——
+  --   我第一版按后者取，于是恒得空列表（判据因此报"应有 2 个源，实得 []"）。
+  --   两种形态都兜住，免得内核换个包装就失效。
+  local arr = ls and ls.json or ls
+  if type(arr) ~= "table" then arr = {} end
+  local out = {}
+  for _, x in ipairs(arr) do
+    if type(x) == "table" then out[#out + 1] = { name = x.name, adapter = x.adapter } end
+  end
+  return { json = { sources = out } }
+end
+
 -- plugin.__trae_entry_probe：只给测试/诊断用 —— 报告某模型最终选中条目的关键字段。
 -- “合并规则选错了条目”（空档位覆盖有档位，issue IKI7WT/IKILR7）这类问题
 -- 没有它只能靠猜。