fix(channels): 渠道鉴权头三修 + 源名契约 + 夹具形状判据

P1-1 anthropic 基座补 build_headers（x-api-key + anthropic-version）
  根因：基座只有静态 anthropic-version、没有 build_headers ⇒ 内核兜底发
  Authorization: Bearer，而 Anthropic 协议要 x-api-key。
  ★ 证据冲突（计划 P1-1 原文一半有误）：zcode 的
  /zcode-plan/anthropic/v1/messages 虽然**说 Anthropic 协议**，鉴权却是
  Bearer <zcode_jwt>（参考 zcode-transport.ts:121-125；全仓 grep x-api-key
  = 0 次命中）。故 zcode 必须**显式覆盖** build_headers 回到 Bearer，
  否则基座的正向修复会把它从"对"改成"错"。
  内核改动：internal/provider/provider.go —— 兜底 Bearer 让位给 x-api-key，
  避免同一请求带两套鉴权（部分 Anthropic 兼容上游对歧义鉴权直接 401）。

P1-2 channels-cline 的 build_headers 补 workos: 前缀
  根因：参考 cline.ts 发 `Bearer workos:<jwt>`，而池里存的是第二步 register
  换回的裸 token ⇒ 之前无 build_headers，内核兜底发裸 Bearer。
  幂等：已带前缀（含大小写变体）不重复拼。

P1-3 channels-gemini 只确认不改
  参考 gemini.ts:353-366 同样是 OAuth Bearer + 身份五头、刻意不发
  x-goog-api-key ⇒ 我们现状本来就对。加判据把这个结论钉住，防下轮照
  P1-1 的模子把它改坏。

P2 源名契约：仅 [A-Za-z0-9_-]，禁 : 与 /
  根因：: 与 / 是限定名分隔符，出现在源名里会让 `源名:模型名` 有两种都
  自圆其说的切法，同一请求串在不同部署下可能路由到不同源，且**不报错**。
  校验加在写入口 core.normalizeSource（硬拒，API 400）；启动时只告警，
  避免存量带 : 的源名让升级 brick 掉整个网关。
  解析入口 splitPinned 不做校验（解析不该拒绝已有数据）。

P3 夹具形状判据（本轮最重要的一条）
  根因：trae 的 Result 信封缺陷在扁平夹具下所有判据全绿，真实登录却报
  「缺少 Token」—— 夹具形状错 ⇒ 判据必然虚假通过。
  通用形状层：shapeFamilies 登记表，每族给 real/naive/fact/eval/assert，
  断言 fact(real) 且 !fact(naive) 且 assert(eval(real))。
  刻意**不比较 eval 输出形状**：trae 余额实现合法保留顶层兼容路径，
  拿输出比对会把合法兼容判成错误；能区分真假的是 fact（额度在哪一层）。
  另有仓库扫描：对特征明确的退化形状静态反查，需退化夹具时写 SHAPE-OK 豁免。

判据：11 个文件 / 30 用例。全部变异已验证会报红（9 处）。

docs/channel-repair-plan.md

@@ -112,34 +112,105 @@
 
 > 判据：`git tag --points-at <release HEAD>` 非空；`git diff release/v2.0.x main` 为空。
 
-### P1 — 其余渠道的同类缺陷（**账号 0，验证不了**）
+### P1 — 其余渠道的同类缺陷（**账号 0，验证不了运行**）
 
 按"风险 × 可验证性"排序。**核心限制：这 4 个平台账号数均为 0，
 无法做生产实测** —— 只能靠静态对齐参考 + 装好适配器后看 `__adapter_install_probe`。
 
 | 优先 | 项 | 缺陷 | 修法 | 可验证性 |
 |---|---|---|---|---|
-| P1-1 | `channels-zcode` | 走 anthropic 基座，而**基座无 `build_headers`**，anthropic 要 `x-api-key` 不是 Bearer | 给基座补 `build_headers`（`x-api-key` + `anthropic-version`），zcode 继承即得 | 静态可验；运行需账号 |
-| P1-2 | `channels-cline` | 参考要 `Bearer workos:<jwt>`，我们的 token 无 `workos:` 前缀 | 登录/续期处拼前缀，或适配器 `build_headers` 补 | 静态可验；运行需账号 |
-| P1-3 | `channels-gemini` | 有静态头 + Bearer（参考注释也说 Cloud Code 用 OAuth Bearer）⇒ **可能本来就对** | 只需确认，不改 | 静态可验 |
+| P1-1 | `anthropic` 基座 | 基座**无 `build_headers`**，Anthropic 协议要 `x-api-key` 不是 Bearer | 给基座补 `build_headers`（`x-api-key` + `anthropic-version`） | ✅ 已修+已判据；运行需账号 |
+| P1-1b | `channels-zcode` | **★ 证据冲突**：zcode 的 Messages 端点虽然**说 Anthropic 协议**，鉴权却是 `Bearer <zcode_jwt>`（参考 `zcode-transport.ts:121-125`，全仓 `x-api-key` 命中 **0** 次）。基座补了 x-api-key 后它**继承就会变错** | zcode **显式覆盖** `build_headers` 发 Bearer，不用继承 | ✅ 已修+已判据；运行需账号 |
+| P1-2 | `channels-cline` | 参考要 `Bearer workos:<jwt>`，我们的 token 无 `workos:` 前缀 | 适配器 `build_headers` 补前缀（幂等，已带不重复） | ✅ 已修+已判据；运行需账号 |
+| P1-3 | `channels-gemini` | 有静态头 + Bearer ⇒ **本来就对**（参考 `gemini.ts:353-366` 也是 OAuth Bearer，且刻意不发 `x-goog-api-key`） | **不改**，只加判据把这个结论钉住 | ✅ 已确认+已判据 |
 | P1-4 | `channels-qoder` | 头由 **WASM 生成必须原样透传**，我们拿不到 `.wasm` | **阻塞**：二进制不在仓库任何位置 | 不可验证 |
 
+> #### ★ P1-1 与 P1-1b 的证据冲突（本轮最重要的一条）
+>
+> 计划原文把 P1-1 写成「anthropic 基座没 `build_headers` ⇒ zcode 继承就 401」。
+> 逆向参考后**两半各对一半**：
+>
+> | 断言 | 结论 | 证据 |
+> |---|---|---|
+> | Anthropic 协议（真 · api.anthropic.com）要 `x-api-key` | ✅ 对 | 协议本身 |
+> | zcode 的 `/zcode-plan/anthropic/v1/messages` 也要 `x-api-key` | ❌ **错** | `zcode-transport.ts:121-125` 发 `Authorization: Bearer ${zcode_jwt}`；`zcode-upstream.ts:83-108` 的 `buildZcodeHeaders` 只有可选 Authorization；全仓 `grep -rn "x-api-key" src/` = **0** |
+>
+> zcode 是「**Anthropic 请求体形状 + Bearer 鉴权**」——协议与鉴权是两个独立维度，
+> 被这家上游拆开了。所以修复不能"把基座改成 x-api-key 就完事"：
+> 那会把 zcode 从「对」改成「错」。正确形态是**基座发 x-api-key + zcode 显式覆盖成 Bearer**。
+>
+> 附带约束：`anthropic` 基座**同时服务生产里的其它源**（`/etc/llmsproxy/config.yaml`
+> 里 `justwoker` 就是 `adapter: anthropic`）。给基座补 `x-api-key` 后，内核
+> `buildHeaders` 的兜底 Bearer **必须让位**（否则同一请求带两套鉴权），
+> 这处改动在 `internal/provider/provider.go`（内核改动）。
+
 ### P2 — 内核对"限定名"的契约收口
 
-`ResolvePinned` / `EffectiveModel` 现在各自调 `splitPinned`。建议：
-- 把"源名可含哪些字符"写进 `docs/`，并加判据：新增源名若含 `:` 或 `/` 必须报警
-  （否则限定名会歧义）。
-- 现状：源名由插件生成 `channels-<platform>-<accountId>`，只含 `-`/字母数字，安全。
+已落地（详见 **`docs/source-name-contract.md`**）：
+
+| 位置 | 行为 |
+|---|---|
+| `config.ValidateSourceName` / `SourceNameWarning` | 纯函数校验器（单一定义） |
+| `core.normalizeSource`（`AddSource` 入口） | 新增/修改源**硬拒**（API 400）—— 新数据从源头合法 |
+| `config.ApplyDefaults`（启动） | 存量带 `:` 的源名**只告警不报错**（避免升级 brick 掉整个网关） |
+
+字符集：**仅 `[A-Za-z0-9_-]`**，禁 `:` 与 `/`（限定名分隔符 ⇒ 切分歧义且**不报错**）。
+`-` 允许（渠道源名 `channels-<平台>-<账号id>` 含 `-`，分隔符在源名之后不歧义）。
+
+解析入口 `internal/provider/splitPinned` **不做校验**（解析不该拒绝已有数据），
+只做最长前缀匹配 —— 校验责任全在写入口，保持解析路径纯函数无副作用。
 
 ### P3 — 判据防回归（防"夹具与生产不一致"再犯）
 
 本轮最大的教训不是某个 bug，而是**夹具形状错 ⇒ 判据虚假通过**（trae 活了两轮）。
 
-建议加一条**通用**判据：`TestAdaptersFixturesMatchRealUpstreamShape` ——
-对每个有夹具的渠道，把夹具响应体与
-`/tmp/pi-github-repos/.../vendor/channel-pack/src/*.ts` 里注释记录的真实响应形状
-做**结构对照**（键集合），不一致即报红。做不到全自动，至少把已知的
-"Result 信封 / SOLO SSE / 嵌套 quota" 三类钉住。
+已落地，分两层（文件：`internal/lua/channels_fixture_shapes_test.go` 行为层 +
+`internal/lua/channels_fixture_shapes_general_test.go` 通用形状层）：
+
+**① 形状登记表 `shapeFamilies`** —— 每族给出四项，缺一不可：
+
+| 字段 | 含义 | 为什么必须有 |
+|---|---|---|
+| `real` | 生产原文（引自实测抓包/参考注释） | 夹具的真值来源 |
+| `naive` | 错误的「方便测试版」 | 证明判据能区分真假，不是恒等式 |
+| `fact(raw)` | 对**原始 JSON 的结构事实** | 判定「这段 body 是不是生产形状」 |
+| `eval` / `assert` | 用**真实实现**处理并断言行为 | 防判据自算一份解包逻辑 |
+
+断言链：`fact(real)` 为真 **且** `fact(naive)` 为假 **且** `assert(eval(real))` 通过。
+
+> ⚠️ 刻意**不比较 `eval(real)` 与 `eval(naive)` 的输出形状**：trae 余额实现
+> **合法保留**了「顶层 credits_limit」兼容兜底路径（实测两种上都返回 600），
+> 拿输出比对会把合法兼容判成错误。真正能区分真假的是 `fact`
+> —— 它问的是「生产响应里额度在哪一层」。
+
+已登记三族（基线，元判据强制不可删）：
+- **Result 信封** —— 凭据在 `Result` 里，顶层只有 `ResponseMetadata`
+- **SOLO 自定义 SSE** —— 正文在顶层 `response`，**无** `choices`
+- **嵌套 quota** —— `pack.entitlement_base_info.quota.credits_limit`（顶层**没**该字段）
+
+**② 仓库扫描 `TestNoDegenerateFixturesInRepo`** —— 扫 `internal/**/*_test.go`，
+对**特征明确**的退化形状做静态反查（当前只留「额度挪到 pack 顶层」一条规则）。
+需要退化夹具来测兼容路径时，必须在文件里写 `// SHAPE-OK: <理由>` 显式豁免。
+
+> 为什么扫描只留一条规则：文本匹配对另两族**必然误报** —— SOLO 判据自己会写
+> `Fatalf("不得返回 choices…")`，天然含 choices。那两族的精确钉法
+> 是 ① 的 `fact` 判据，不是文本匹配。
+
+#### 本轮修复的判据清单（P1/P2/P3）
+
+| 判据文件 | 用例数 | 钉住什么 |
+|---|---|---|
+| `internal/lua/adapter_anthropic_headers_test.go` | 3 | 基座发 `x-api-key`+`anthropic-version`（恰好 2 键）、不发 Authorization、无凭据不发空头、读 `source.meta.api_key` 兜底 |
+| `internal/lua/adapter_zcode_build_headers_test.go` | 3 | zcode **覆盖**成 `Bearer`、无 `x-api-key`；基座 vs zcode 鉴权**真的不同**；无凭据不发空头 |
+| `internal/lua/channels_cline_workos_test.go` | 3 | 无前缀补上 / 已有不重复 / 大小写变体不重复；无 token 不发 `Bearer workos:` |
+| `internal/lua/channels_gemini_auth_check_test.go` | 2 | **P1-3 结论**：gemini 不自带鉴权（身份五头 + 兜底 Bearer 即正确），不得发 Authorization/x-api-key/x-goog-api-key |
+| `internal/provider/build_headers_fallback_test.go` | 2 | 内核兜底让位给 x-api-key；其它适配器 Bearer 行为**不变** |
+| `internal/config/source_name_contract_test.go` | 4 | 允许字符集、`:`/`/` 点名拒绝、其它非法字符、存量只告警 |
+| `internal/core/source_name_contract_test.go` | 2 | **真实写入口** `AddSource` 硬拒且拒绝发生在写盘之前；合法渠道名照常接受 |
+| `internal/lua/channels_fixture_shapes_test.go` | 4 | 三族行为层：Result 信封 / SOLO SSE / 嵌套 quota + 元判据 |
+| `internal/lua/channels_fixture_shapes_general_test.go` | 3 | 通用形状层：`fact(real)&&!fact(naive)&&assert(eval(real))`；仓库扫描；登记表自检 |
+| `internal/core/adapter_install_probe_test.go` | 1 | `__adapter_install_probe` 报告 6/6 自装适配器全绿（`luac -p` 对长字符串无效） |
+| `internal/lua/adapter_zcode_harness_test.go` | —（辅助） | 兄弟目录测试台：自带 zcode 装载断言，装不上就响亮失败 |
 
 ### P4 — 待用户决策
 

docs/source-name-contract.md

@@ -0,0 +1,109 @@
+# 源名与限定名契约
+
+> 本文只说一件事：**源名允许哪些字符，以及为什么**。
+> 判据：`internal/config/source_name_contract_test.go`、`internal/core/source_name_contract_test.go`。
+
+## 1. 契约
+
+| 项 | 值 |
+|---|---|
+| 允许字符集 | **仅 `[A-Za-z0-9_-]`** |
+| 禁止 | **`:`** 与 **`/`**（限定名分隔符，见下） |
+| 其它禁止 | 空白、换行、`.`、`+`、`@`、非 ASCII 等一切不在允许集内的字符 |
+| 长度 | 非空（上限未强制，但超长源名无实际用途） |
+
+合法的真实形态（本仓渠道源）：
+
+```
+channels-trae-b8dd6b3df30e
+channels-buddy-buddy-main
+channels-zcode-<accountId>
+```
+
+注意 `-` **是允许的**：渠道源名天生含 `-`，而 `-` 作分隔符时是「源名之后」
+才出现，不产生歧义。
+
+## 2. 为什么禁 `:` 与 `/`
+
+### 2.1 背景：限定名是**有意设计**，不是兼容尾巴
+
+网关支持 `源名:模型名` 这种**限定名**来指定「从哪个源调用」：
+
+```
+channels-trae-b8dd6b3df30e:Doubao-Seed-2.1-Pro
+```
+
+这不是历史包袱 —— 生产实例里 **44 个模型被多个源同时提供**
+（`glm-5.2` 由 6 个源提供），WebUI 的模型下拉框用 `源名:模型名` 作
+option value。没有限定名，用户就无法指定源。
+
+`:` / `/` / `-` 三种分隔符都支持（历史写了三种，都保留）。
+
+### 2.2 根因：源名含分隔符 ⇒ 限定名有**两种都自圆其说**的切法
+
+剥离源名的那一步是 `internal/provider/splitPinned`：先按**已知源名做最长
+前缀匹配**，命中后要求源名之后紧跟一个分隔符。
+
+若源名**自己含** `:` 或 `/`，那个字符同时是「源名的一部分」和「分隔符」：
+
+| 源名 | 模型 | 限定名 | 可能的切法 |
+|---|---|---|---|
+| `a:b` | `m` | `a:b:m` | `("a", "b:m")` 或 `("a:b", "m")` |
+| `a/b` | `m` | `a/b/m` | `("a", "b/m")` 或 `("a/b", "m")` |
+
+两种切法都能自圆其说，结果取决于**当前恰好存在哪些源名** —— 也就是
+同一个客户端请求串，在不同部署、不同启动顺序下可能落到**不同的源**。
+
+更糟的是它**不会报错**：`splitPinned` 会命中某一个分支，然后路由到别处。
+历史上这一族缺陷就非常难查：
+
+> `IndexAny(model, "-:/")` 按**第一个**分隔符切，把
+> `channels-trae-b8dd6b3df30e:Doubao-Seed-2.1-Pro` 切成 `src="channels"`、
+> `model="trae-b8dd6b3df30e:..."` ⇒ 源名永不匹配 ⇒ `Resolve()` 返回 nil
+> ⇒ 客户端看到 `model "channels-trae-xxx:..." is not configured`。
+> 用户只看到「模型不能用」，完全看不出是字符串切分错了。
+
+所以约束必须放在**写入口**，而不是每次解析时去猜。
+
+## 3. 校验加在哪（三个位置，职责不同）
+
+| 位置 | 函数 | 行为 | 为什么在这儿 |
+|---|---|---|---|
+| **写入口（硬拒）** | `core.normalizeSource`（`internal/core/core.go`） | `AddSource` 返回 error（API 400） | WebUI 新增/修改源、插件 `add_source` 都走这里。**新数据必须从源头就是合法的** |
+| **启动（只告警）** | `config.ApplyDefaults`（`internal/config/config.go`） | `log.Printf` 一行，**不返回 error** | 存量配置可能已有带 `:` 的源名。升级瞬间让网关起不来比「限定名歧义」更坏 —— 整个服务不可用 |
+| **校验器本体** | `config.ValidateSourceName` / `config.SourceNameWarning` | 纯函数 | 单一定义，上面两处都调它，不会漂移 |
+
+**解析入口（不在上面三处，但需要知道）**
+：`internal/provider/registry.go` 的 `splitPinned` 是限定名的**解析**入口，
+`Resolve` / `ResolvePinned` / `EffectiveModel` 三个都用它。
+它**不做校验**（解析不该拒绝已有数据），只做最长前缀匹配 + 分隔符判定。
+校验的责任全在写入口 —— 这样解析路径保持纯函数、无副作用。
+
+## 4. 存量数据怎么办
+
+启动时告警、不阻断：
+
+```
+[config] source name "legacy:v1" contains ":", which is a reserved pinning
+separator; "legacy:v1" is ambiguous (source names allow only [A-Za-z0-9_-])
+  — `source:model` pinning may resolve to the wrong source
+```
+
+运维看到告警后可以：
+- 改名（推荐，WebUI 里编辑即可 —— 改名后 `channels-*` 源会在下次账号同步时重建）
+- 或者继续用，但**不要**对这种源使用 `源名:模型名` 限定名（用「模型 + 源」的
+  显式槽位，即 AUTO 链里的 `(model, source)` 对，那条路径不经过 `splitPinned`）
+
+## 5. 判据覆盖
+
+| 判据 | 文件 | 钉住什么 |
+|---|---|---|
+| `TestValidateSourceNameAllowsContractCharset` | `internal/config/source_name_contract_test.go` | 合法集（含真实渠道源形态、含 `-`）不被误拒 |
+| `TestValidateSourceNameRejectsPinningSeparators` | 同上 | `:` / `/` 被**点名**拒绝（错误文案含 `pinning separator` + 回显源名） |
+| `TestValidateSourceNameRejectsOtherIllegalChars` | 同上 | 空白/换行/`.`/`+`/`@`/非 ASCII/空串 |
+| `TestSourceNameWarningIsSoftForLegacyConfig` | 同上 | 存量带 `:` 能启动（不 brick），且有告警文案 |
+| `TestAddSourceRejectsPinnedSeparatorInName` | `internal/core/source_name_contract_test.go` | **真实写入入口** `Core.AddSource` 硬拒，且拒绝发生在写盘之前 |
+| `TestAddSourceAcceptsChannelStyleNames` | 同上 | 真实渠道源名照常接受（防校验器写太严把渠道全废掉） |
+
+> 写入口那条特意在 `internal/core` 而不是 `internal/config`：校验器写对了但
+> **没接到入口上**，问题依旧存在 —— 两条判据分别咬「规则对不对」和「规则有没有被调用」。