[SsuJojo]

背景 / Problem

把**同一个账号（同一提供商家族）**里的多个上游模型映射到同一个对外名（比如 free）时，只有按配置顺序的第一条生效，其余全是"影子条目"：

• 模型页上每条映射都显示、都算数；
• 但路由层 builtin_target 只返回第一条 —— free 的流量永远打到先建的那条；
• 第一个模型撞了限额（429）只能换账号，模型本身没有后备。

而同名映射挂在不同提供商（跨家）早已是"按账号全局优先级主备切换"的候选链 —— 家内却不是。这个 PR 把家内也接上同一个算法。

Mapping several upstream models of the same provider family to one public alias (e.g. free) today leaves only the first mapping effective; the rest are unreachable shadows — quota exhaustion on one model can only be answered by switching accounts. Same-name mappings spread across providers (cross-family) have long formed a priority failover chain; in-family ones do not. This PR gives in-family mappings the same algorithm.

方案 / Approach

候选粒度从「家」细化到「家 × 上游模型」，两层各管各的：

• 家（route_for_forward，不变）：谁有资格承载这个名字；
• 家 × 模型（新增）：这一家先发哪个模型，撞了再换下一个。

具体：

1. catalog::target_candidates（新）：按「原生承载（有则独占）→ Cline 池前缀项 → 其余映射（配置顺序）→ 旧版全局条目」给出全部候选。链首与改造前的单一答案逐字相等，存量配置行为不变；原生命中依旧短路（映射不进链）。
2. provider_loop 位次游标（lane）：账号循环的每轮内，模型作用域的失败（限额 429 / 上游 404）先在本账号内换下一位 —— 开一条新尝试明细、不吃换号预算、不触发退避 / 熔断（404 是模型的事实，不是账号健康的问题）；链走完才顺延下一个账号。模型测试（pinned）不顺延。
3. lane_targets 免费优先：已限额的目标稳定排到链尾（组内保持配置顺序，不按名称排序）；全部在冷却时按原序硬试 —— 与选路第二级「恢复最早的试一次」同一取舍。
4. 冷却逐位判定：CooldownKeys 缓存整条链（for_provider_all）；rate_limit_reset_at 改为「任一目标可用 = 账号可用」，全部在冷却时报最早的恢复时间。否则会出现「第一个目标撞限额、第二个目标明明有额度，账号却被整条摘掉」的浪费。
5. send_body 显式目标：转发层按位传 wire，"一次解析、两处消费（字节 + 冷却键）"的同源约束保持不变。
6. send_cache 键带目标名（复核补丁）：键的第四维不能是位次序号 —— 位次 → 目标是按账号算的（第 3 条的免费优先分区），同家同池的两个账号会把不同目标排在同一位次上，用序号做键时第二个账号会命中第一个账号那一档的发送体（发错模型、429 记到错误的真名）。改为 (家, 池, 降级, 目标名)。

每条候选都是不同的上游模型 = 不同的额度桶，这正是"撞一个模型的限额就换另一个模型"成立的前提。

兼容性 / Compatibility

• 单目标配置（绝大多数）：候选链只有一位，for_provider 取链首、rate_limit_reset_at 的"任一可用"退化成"那一位可用" —— 与改造前逐字等价。
• 模型页、/v1/models、思考等级绑定、Key 白名单、会话粘性：口径均不变（别名仍按对外名去重广告一次）。

测试 / Tests

新增 15 个用例（catalog::routing::tests / core::routing::tests / upstream::provider_loop::tests）：

• 家内同 alias 多映射 → 有序链（首位 = 旧答案，锁向后兼容）；
• 原生承载独占（映射不进链）；Cline 池前缀优先、其余按配置序跟随；
• 配置顺序而非字典序；关闭的映射剔除；别家映射不进本家链；
• 冷却：任一目标可用 = 账号可用；全冷却报最早恢复时间；过期条目算可用；for_provider 取链首 + 解析不出回落请求名；
• 链序契约（order_lane）：稳定分区（组内保持配置序）、全免费不动、全冷却按原序硬试；
• send_cache 键契约：同一位次不同目标必须是两条缓存项（同家同池跨账号不串档）。

cargo test --release -p agent2api-server --lib：534 passed / 66 failed —— 那 66 个「临时 SQLite 目录拒绝访问（os error 5）」的环境性失败与 base 68d0a4e 逐条同名（基线 519 passed / 66 failed），新增用例全部通过。

New tests cover chain ordering (head equals the old single answer), native exclusivity, Cline pool-prefix preference, config-order stability, disabled-mapping exclusion, per-target cooldown, the free-first ordering contract and the send-body cache-key contract. The ~66 "temp SQLite directory access denied" failures on this machine are pre-existing environment issues, reproducible on a clean checkout.

已知边界 / Known limits

• 自定义提供商：映射解析（custom_providers::bindings::resolve）仍是单答案，本 PR 不动 —— 它有独立的数据源与转发路径，摊平属于同构的后续工作；
• 有状态路径（CatPaw）：维持单目标解析 —— 该路径没有账号内重试机制（上游无轮换信号，见 attempt_stateful 的说明），先不引入。

行为不变，只是"家内多模型同名"暂时仍取首条；后续如需可以按同一模式补上。

• Custom providers: mapping resolution stays single-answer (separate data source and forward path; same-shape follow-up).
• Stateful path (CatPaw): stays single-target (no in-account retry mechanism exists there by design).

验证方式 / How to verify

同一账号（如小浣熊）勾选两个模型，各加一条同名映射（如 free）：

1. model: "free" 请求 → 发送主位模型；
2. 把主位模型在账号上打满（或临时给它一条 429）→ 下一条 free 请求自动落到第二位模型，请求日志出现「家内候选顺延 → <模型>」与两条尝试明细；
3. 第二位也限额 → 账号页两个真名都在冷却，请求顺延到下一个账号。