背景
MultiRouter 模型选择的语义与运行时路由不一致，共三个相互关联的缺陷（v3.19.2-16 实测）。前两个与本仓库 #29 相关但属于补充语义；第三个是取消 fallback 后暴露的既有缺陷。
问题
1. include 反选被前缀匹配放行
官方 route 是 include 模式（精确白名单 ["gpt-5.6-sol","gpt-5.6-terra","gpt-5.6-luna"]），但向导生成的 matchPrefixes=["gpt","o"] 使前缀匹配独立于 include（"或"关系而非"与"关系）。被反选的 gpt-5.4/5.5 仍可通过 startsWith("gpt") 命中官方 route：
- 前端
routeCanMatchVisibleCatalogModel、后端 codex_route_matches_model、codex_catalog_route_matches_model、database route_matches_model 四处 exact OR prefix 同一缺陷；
- 表现：排序界面/子 agent 界面仍能选到反选模型，运行时仍路由到官方。
2. 无匹配模型 fallback 到默认路由（官方）
未勾选源（如 Qwen/Bitto）没有 route，其模型（qwen3.8/glm-5.3）在 exact/prefix 均不匹配后 fallback 到 defaultRouteId/第一条 enabled route（官方）：
- 真实请求打到 OpenAI 官方（404）；
- 子 agent 分组误判"官方"。
- 代码注释自述为 historical behavior，但语义上"反选/未勾选 = 明确排除"与之冲突。
3. mode=all 且 matchPrefixes 为空的路由，其模型误判不可路由
Kimi route 为 mode=all 且 matchPrefixes=[]（向导 inferWizardRoutePrefixes 不识别 "Kimi"，未生成前缀）。raw settings 匹配（exact OR prefix）无法命中 k3/k3-256k：
建议修复
- include 模式下前缀匹配必须同时命中 include 列表（"与"语义，统一 4 处）；
- 无匹配模型一律 fail-closed（不可路由），不 fallback 默认路由；
- mode=all 路由按 target provider catalog 匹配其全部模型（与编译层对齐）。
对应 PR：#（待 PR 创建后回填）
背景
MultiRouter 模型选择的语义与运行时路由不一致，共三个相互关联的缺陷（v3.19.2-16 实测）。前两个与本仓库 #29 相关但属于补充语义；第三个是取消 fallback 后暴露的既有缺陷。
问题
1. include 反选被前缀匹配放行
官方 route 是 include 模式（精确白名单
["gpt-5.6-sol","gpt-5.6-terra","gpt-5.6-luna"]），但向导生成的matchPrefixes=["gpt","o"]使前缀匹配独立于 include（"或"关系而非"与"关系）。被反选的 gpt-5.4/5.5 仍可通过startsWith("gpt")命中官方 route：routeCanMatchVisibleCatalogModel、后端codex_route_matches_model、codex_catalog_route_matches_model、databaseroute_matches_model四处exact OR prefix同一缺陷；2. 无匹配模型 fallback 到默认路由（官方）
未勾选源（如 Qwen/Bitto）没有 route，其模型（qwen3.8/glm-5.3）在 exact/prefix 均不匹配后 fallback 到 defaultRouteId/第一条 enabled route（官方）：
3. mode=all 且 matchPrefixes 为空的路由，其模型误判不可路由
Kimi route 为
mode=all且matchPrefixes=[]（向导inferWizardRoutePrefixes不识别 "Kimi"，未生成前缀）。raw settings 匹配（exact OR prefix）无法命中 k3/k3-256k：collect_candidates的CodexModelSelection::All => None本就正确收集 target 全部模型，raw settings 分类层缺这一语义（两层不一致）。建议修复
对应 PR：#（待 PR 创建后回填）