fix(chat): declare output route fact for uncatalogued models

[asto18089]

Background

After PR #210 removed the global DEEPSEEK_MAX_OUTPUT_TOKENS=24576 injection, uncatalogued models on user-configured OpenAI-compatible endpoints fell back to the foundation's conservative Uncatalogued(8192) output guess, inconsistent with the documented-model window heuristic (>=500K -> 64K, else window/2). Upstream Hmbown/CodeWhale#5461 (merge d03260ec) resolved this foundation-side: an explicit output_tokens route fact replaces the uncatalogued guess, routes without a fact stay fail-closed, and Documented ceilings remain authoritative. The published pinvou-v0.9.5-r11 baseline (synced by #367) carries that change, so this PR is now a pure app-side feature (3 files, +243/-9).

History: the original revision used an ApiProvider::Openai whitelist (Pinvou/CodeWhale#8), which the CodeWhale maintainer closed on 2026-08-17 in favor of the narrower upstream #5461 semantics; intermediate revisions backported #5461 pending the r11 tag. All foundation parts are fully absorbed into main via #367.

Changes

1. route_limits_for_model (pinvou3-app/src-tauri/src/features/assistant/platform/bridge.rs): endpoints that are operator-owned — the OpenAI-compatible preset or provider_kind=custom, excluding the official coding_plan managed entry (prefs normalize the kind by endpoint URL) — declare an output_tokens route fact per the base window heuristic: >=500K -> 65536, else min(window/2, 65536), 64000 when no window fact exists (half of the 128K fallback). A declared >= 4096 gate keeps degenerate tiny windows undeclared. Official endpoints stay base fail-closed. Priorities unchanged: SavedModel.max_output_tokens still wins and is clamped by the process 24K budget; local vLLM keeps its explicit 24K.
2. Guard test forkguard_cloud_models_defer_output_cap_to_base (six cases): documented cloud models stay undeclared / custom endpoints declare the heuristic (E=128000-64000-1024=62976; fails if the base lacks #5461) / official endpoints stay fail-closed at E=118784 with the host's real route product fed into the base budget / coding_plan excluded / tiny window (2K) undeclared and 16K -> 8192. The existing unknown_cloud_model_does_not_gain_a_speculative_route_limit and compaction assertions follow the same semantics, and the test env guard also isolates CODEWHALE_MAX_OUTPUT_TOKENS / DEEPSEEK_PROVIDER.
3. Register: docs/fork-modifications(.en).md parent-side adapter lines note the capability.

Semantic notes (intentional boundaries, unchanged from the review discussion): small windows still clamp to window/2; uncatalogued names on official endpoints keep the 8192 conservative guess by design (missing declaration is not permission).

Verification (current head 7912e7741, rebased onto main 794a13d10 / r12 baseline)

Rebase note: the register conflict reported on e8671f07f is resolved — main's r12 inventory in docs/fork-modifications.md (drift/guard rows and the r12 section) is preserved byte-exact, and this PR's parent-side adapter entry is re-anchored into the current 父仓适配 row; the English register change still applies to the unchanged r11 output-ceilings bullet. The CodeWhale gitlink is untouched by this PR and resolves to main's published r12 (9c5f4f19).

• Targeted bridge tests on the combined tree: forkguard_cloud_models_defer_output_cap_to_base, forkguard_cloud_route_output_not_pinned_by_global_env, forkguard_openai_compatible_route_uses_declared_limits, unknown_cloud_model_does_not_gain_a_speculative_route_limit, plus the route_limits / compaction_cloud family — 7/7 pass
• ./scripts/fork-guard.sh --fast: fingerprint layer pass
• ./scripts/verify-public-submodule.sh: pinvou-v0.9.5-r12 -> 9c5f4f19 pass (main's script, untouched by this PR)
• python3 scripts/architecture-guard.py: pass
• python3 -m unittest scripts.tests.test_ci_gate_policy: 19/19 pass
• cargo fmt --check clean; scripts/validate-commit-msg.py pass; git diff --check clean

Known pre-existing main condition observed while testing (unrelated to this PR, untouched here): cargo test --locked wants member versions 0.8.7 -> 0.8.8 in pinvou3-app/src-tauri/Cargo.lock after the #374 version bump; the lockfile is left as-is pending a standalone main fix.

[asto18089]

审计结论（已 rebase 到最新 origin/main 验证）

根因与修复

PR #210 移除 DEEPSEEK_MAX_OUTPUT_TOKENS=24576 全局注入后，未登记 openai-compatible 模型（模型表/catalog 均无）的输出上限落到底座 provider_capability().max_output 的保守 fallback 4096，与底座窗口启发式（≥500K→64K、否则 window/2）不一致——128K 窗口本应 64000 却被压成 4096。上游 #8 三处 4096→65536（= API_MAX_OUTPUT_TOKENS）使 min(requested_cap, 65536) = requested_cap 恒成立，未登记模型直接对齐窗口启发式。链路逐段核验：品悟 route_limits_for_model 云端模型不夹带 output_tokens（未登记整条返回 None），真实请求 max_tokens（effective_max_output_tokens_for_route）从 4096 → 64000 生效。

安全性（无新缺陷）

• 小窗口仍按 window/2 钳制不过发（Ollama 8K → 4096；ContextBudget 有 clamp 保护）
• 本地 vLLM 24K（is_local_vllm 分支）、OpenaiCodex 4096 特例（OAuth 无能力元数据）、DEEPSEEK_MAX_OUTPUT_TOKENS env override、≥500K 大窗口 262K 输出预留均不受影响
• 已登记模型 catalog 命中不受影响；provider_capability 其余调用点（doctor/model_inventory/model_profile/context_report）只读展示或窗口字段，无行为风险
• 底座 kimi_catalog_output_ceiling_preserves_input_budget 失败：经代码路径分析该测试走 route_output_limit_tokens 分支（route_limits.output_tokens=Some(262144) → min(requested_cap, 262144)），不经过 provider_capability，feat: 优化侧边栏搜索与导航布局 #8 前后同样失败，"既有基线失败、与本次无关"属实

守护测试

forkguard_cloud_models_defer_output_cap_to_base 三个断言分别守护「云端已登记不声明 output_tokens / 未登记 route_limits 返回 None / 底座 128K 窗口 E=62976」；若底座 fallback 回到 4096（E=122880）即失败，守护有效。

验证（rebase 到最新 main 后实测）

• 品悟 forkguard 全系列 16/16 通过（含新测试）
• 底座 provider_capability 30/30 通过；route_budget 3/4（kimi 为既有失败）
• ./scripts/fork-guard.sh --fast 全过；docs drift 数字（+4863/-626、60 文件）与 git 实测一致
• rebase 无冲突（PR 落后 main 一个 commit refactor(tools): i18n 合规修复 + ToolStoreView dead 重复代码删除 #151，cherry-pick 后 3 个文件与原始完全一致）

结论

根因真实、修复彻底且优雅（修复全在底座，品悟只加守护测试+文档登记，无重复造轮子）、无无关修改（仅 gitlink/docs/测试 3 文件）、无新缺陷。可合并。唯一补充：建议按 Pinvou/CodeWhale#8 → #210 → #216 顺序合并（#216 生产生效依赖 #210 移除 env 注入；#210 单独合并不含本 PR 时未登记模型会被 4096 压死）。依赖说明已补充进 PR 描述。

[asto18089]

审计完成，已把 PR rebase 到最新 main（f760f47f）并解决全部冲突。核心结论如下。

结论：根因真实、修复对症、可合并（有一个语义边界建议澄清）

1. 根因真实且被彻底解决：PR fix(chat): 放开云端模型输出上限，落底座 64K 兜底 #210 移除 DEEPSEEK_MAX_OUTPUT_TOKENS=24576 注入后，未登记模型走底座 provider_capability().max_output = None → Uncatalogued(8192) 保守 clamp，输出被压到 8192，与已登记模型的 64K 窗口启发式不一致。本 PR 通过 CodeWhale 白名单纳入 ApiProvider::Openai，未登记 alias 走 RouteDeclaredUnknown（不 clamp）→ 128K → 64000，根因消除。

2. 有意义、方法优雅：接入第三方 OpenAI 兼容端点是品悟核心场景，此修复是 fix(chat): 放开云端模型输出上限，落底座 64K 兜底 #210 的语义补全；底座改动仅 13 行，复用既有 allowlist 机制，无重复造轮子。

3. 无无关修改、无新缺陷：7 个文件均为核心改动 + fork 公约配套（docs/fork-guard/测试）。CodeWhale route_budget 11/11、品悟 forkguard_* 21/21、fork-guard.sh --fast 全过。

rebase 说明

• 因 main 的 CodeWhale gitlink 已推进到 2eceab4e（docs(governance): 补齐开源社区治理 #11 并入），原 gitlink 72c653032 与其是兄弟 commit，故把 output-cap 改动 cherry-pick 到 2eceab4e 之上，生成第 8 个 fork commit 1aff9dd73，并已推送到 CodeWhale PR feat: 优化侧边栏搜索与导航布局 #8（Pinvou/CodeWhale#8 现 head = 1aff9dd73）。
• 品悟侧 gitlink → 1aff9dd73，fork-guard.sh 基线 7→8，docs r5→r6，drift 49 files +2190/-271。
• 顺带修了 fork-guard.sh 一处硬编码文案（green 信息写死"7 个提交"，改为 ${EXPECTED_COMMITS}）。

一个语义边界建议（非阻断）

ApiProvider::Openai => true 覆盖的是所有 OpenAI wire route，不止 PR 注释所说的"用户自定义 base_url"，还包括官方 api.openai.com、Gemini、Qwen、腾讯的 OpenAI 兼容端点。因此"官方端点 + 未登记模型名"也会放开到 64000，可能过发（真实上限 < 64K 时 API 报 400）。已登记模型不受影响（走 Documented）。这是可辩护的权衡（宁可过发报错、不静默压死输出质量），但建议把注释里的 "user-configured base_url" 澄清为"所有 OpenAI wire route（含官方端点）"，避免误导后续维护者。

合并顺序依赖

需先合并 Pinvou/CodeWhale#8（现 head 1aff9dd73），再合本 PR，否则 gitlink 目标在 Pinvou/CodeWhale 不可达。

[zhuowp]

复核当前 head 后，本 PR 与最新 main 存在真实内容冲突（GitHub: mergeable=false / dirty；当前约落后 44 个提交），因此无法确认冲突解决后的最终行为，也不能直接合并。当前 checks 同时失败。

请同步最新 main，保全双方可共存语义并按最终源码重跑适用门禁后重新请求审核。

[zhuowp]

复审当前 c5001d5a：输出上限语义与 app 守护测试本身未发现问题，且当前与 main 可自动合并；但仍有 1 个 P1 与 1 个 P2，不能批准。

• P1 公开底座门禁：父仓 gitlink/guard 指向 0661776cda6d2323f3fd182a686e66d57d40f90b，公开不可变标签仍是 pinvou-v0.9.5-r7 -> a36e6cd533024cfe5724bae21875aea42b2ed87a。因此 verify-public-submodule.sh、线上 fast-gate 和 required-gate 均确定失败。必须先将 CodeWhale 变更合入公开维护分支并发布新不可变 tag，再把 gitlink、验证脚本、guard 和双语登记统一到最终 commit。
• P2 PR 正文严重过期：正文仍声称 gitlink 72c653032、CodeWhale #8 待合并、7 个线性 commit，并依赖已过时的 #210 合并顺序；实际树是 r7 上的 0661776cd、10 个 commit，当前 fork register 也写成另一套状态。请按最终差异、真实依赖、最终测试结果和发布风险重写正文。

当前 windows-rust-test/rust-lint 成功；除公开基线和元数据外无新增 finding。

[asto18089]

@zhuowp 已按两轮复审意见完成修复并重写（head f70c265fc，rebase 到 origin/main 5c6253bf 无冲突），逐条回应：

P1 公开底座门禁 — 属实，但修复路径与「发布 0661776cd」不同

门禁红根因确认无误：verify-public-submodule.sh 要求 gitlink 与不可变标签一致，而 0661776cd 在公开仓库完全不可达。但直接把该 commit 发布到 pinvou3-clean 并打标不可行——CodeWhale 维护者 h3c-hexin 已于 2026-08-17 关闭 CodeWhale PR #8（该 commit 的来源），理由是该问题已按更窄语义上游化并由上游合并：Hmbown/CodeWhale#5460 / #5461（merge d03260ec，作者即 h3c-hexin 本人）。上游明确不接受 ApiProvider::Openai 白名单方案（会连带放开官方端点的未登记模型名）。

因此修复改为后向移植上游已合并的 #5461：

• CodeWhale PR #21：r8（d127aed11，pinvou-v0.9.5-r8）之上 cherry-pick 上游 d03260ec 的 route_budget.rs 净变更（diff 与上游逐行一致，仅行号偏移），待维护者合并并发布 pinvou-v0.9.5-r9
• 本 PR gitlink → 2645c6c63（= 移植分支 head）；verify-public-submodule.sh → 按 pinvou-v0.9.5-r9 校验。r9 发布前该脚本按设计失败（与当前行为一致，方向明确：gitlink 不接受浮动分支/PR ref）；r9 发布后标签、分支、gitlink 三者对齐，门禁转绿
• app 侧配套：operator-owned 判定（OpenAI 兼容 预设或 provider_kind=custom）留在品悟 route_limits_for_model，按窗口启发式声明 output_tokens 路由事实；官方端点保持底座 fail-closed——这正好消除了白名单方案「官方端点过发」的原语义边界问题

即 P1 的最终解是「维护者发布 r9 → 三点对齐」，与你的要求方向一致，只是标签内容换成了维护者认可的上游修复而非被拒的 #8 commit。

P2 PR 正文严重过期 — 已重写

正文已按最终差异全量重写：gitlink 2645c6c63、CodeWhale #8 已关闭及上游替代链路、r8 基线 + 后向移植的真实 drift（49 files +3303/-476，其中 #15 系维护者已发布基线本身 +1449 行）、fork register（fork-modifications(.en) / fork-policy(.en) 双语）同步重写、真实测试结果与合并依赖（#21 合并 → r9 发布 → 本 PR）。

顺带修复

• r8 fix: 统一侧边栏定时任务记录样式 #15 的 turn_tool_security 字段适配（EngineConfig/Op::SendMessage 透传 default，维持 fork「显式列字段」惯例）
• 守护测试 forkguard_cloud_models_defer_output_cap_to_base 重写为四断言（已登记不声明 / 自定义端点声明启发式 / 底座新臂 E=62976，底座缺 #5461 即失败 / 官方端点 fail-closed E=118784）
• unknown_cloud_model_does_not_gain_a_speculative_route_limit 同步新语义（context 仍不投机，output 声明启发式）

验证：CodeWhale 移植分支 route_budget 12/12；父仓 fork-guard.sh 全层 ✅（34/34 + 20/20）、architecture-guard.py ✅、bridge 套件 87/88（唯一失败 code_session_tool_shaping 在 main 本机同挂，系环境存量与本 PR 无关）、cargo test --locked 通过（底座改动无依赖变化，Cargo.lock 无需更新）。

待 CodeWhale #21 合并 + r9 发布后门禁即绿，请重新审查。

[zhuowp]

Re-review of f70c265fc: the app-side output-limit semantics and updated description address the prior conceptual findings, but the branch is no longer publishable or integrable as written:

1. [P1] The claimed r9 foundation target is stale and cannot satisfy the public gate. This branch points CodeWhale at 2645c6c630 and configures pinvou-v0.9.5-r9; the immutable public r9 tag now resolves to a different commit, 07d183e350, while current main is on public r10 feb8761aed. Consequently the branch's required/fast gates fail and waiting cannot make this gitlink match r9. Restack the behavior on the current published baseline (upstream first as required), publish any still-needed foundation change under the next immutable tag, then align the gitlink, verifier, guard fingerprints, and bilingual register to the final SHA.

2. [P1] Resolve the current-main conflicts semantically. The merge tree reports conflicts in the CodeWhale gitlink, four fork-policy/register files, assistant/platform/bridge.rs, fork-guard.sh, and verify-public-submodule.sh. Preserve current r10 behavior and the intended route-limit semantics, then rerun the actual combined gates.

3. [P2] Update PR collaboration metadata to English. The current PR title and developer-facing description are Chinese; AGENTS.md requires PR titles/descriptions and repository collaboration to be English.

git diff --check and commit-message validation pass, but the PR remains non-mergeable with two failing required gates.

[asto18089]

Rebase 到最新 main + r11 对齐 + 审阅代修（d2c123c96）

基线更新：gitlink 改钉已发布的 pinvou-v0.9.5-r11

本 PR 旧方案假设「#21 合并后维护者发布 r9 = 移植 commit」。实际世界线是：CodeWhale PR #21 已 squash 为 485884913 并入 pinvou3-clean，随后 #22/#25/#26/#30/#18（严格直连大小写，即父仓 PR #295 的子模块配对）继续前进，维护者发布了 r11 标签 = 0d89a31be = 分支 tip。按 fork 政策「发布后 gitlink、维护分支与不可变标签三者对齐」，本次 rebase 不再造私有 drift 提交，而是把 gitlink 直接对齐 r11：

• r10→r11 的 15 个提交全部为维护者公开历史（依赖通告/shell 解码/CI、chore(deps): bump postcss from 8.5.16 to 8.5.23 in /pinvou3-app #21 移植本体、Moonshot 降级、宿主 MCP 钩子、MCP 封闭、steer 撤回、大小写归一），已逐一对照合并记录核验；
• route_budget.rs 在 r11 与旧移植版 diff = 0 行，语义无损；
• verify-public-submodule.sh → r11；fork-guard.sh PUBLISHED_HEAD=r10(feb8761ae) 祖先断言保留、EXPECTED_HEAD=r11、EXPECTED_COMMITS=29（rev-list 复核）；四份 fork 文档以 r11 口径重写登记。

rebase 中消除的冲突副作用

r10+ 的 main 已原生包含 CodeWhale #15（turn_tool_security），engine.rs 自动合并把本 PR 旧的 r8 适配重复注入 bridge.rs（E0025/E0062）。已删尽三处冗余适配——bridge.rs 相对 main 归零后仅剩 route_limits_for_model 本体与测试。

审阅代修（六项）

1. Cargo.lock 最小同步：r11 将 lru 0.16→0.18（RUSTSEC-2026-0253），父仓 lock 需连带更新。只提交 lru 链路三个 hunk（tui 引用 / lru 0.18.2 条目 / kasuari 双版本消歧）；getrandom 翻转经两轮幂等解析证实非必需、成员版本号行为 main 既有陈旧，均不入本 PR。
2. coding_plan 排除出 operator 判定：prefs 会按端点 URL 自动把 kind 归一为 coding_plan 而 preset 残留 OpenaiCompatible，官方托管入口会被误声明。新增排除 + 用例 E 锁定 fail-closed。
3. 极小显式窗口门：窗口 ≤4K 时输出半区不足 2K，原逻辑产出 Some(<2K) 退化事实；加 declared >= 4_096 门回退不声明 + 用例 F。
4. 测试 env 守卫补齐：底座 requested_cap 先读 CODEWHALE_MAX_OUTPUT_TOKENS，provider 选择读 DEEPSEEK_PROVIDER，精确数值断言一并隔离。
5. D 分支改传宿主真实路由产物（而非字面 None）：把「官方端点不声明」从恒真断言升级为行为锁定。
6. 登记修正：scripts/tests/test_ci_gate_policy.py 的 tag 断言随 r11 同步（否则 fast-gate 红）；文档验证节 41→56 条 CodeWhale forkguard、app 21→22 条；注释「声明值恒等于底座 requested_cap」改为准确表述（取值源不同，底座 min() 向下兜底）。

披露项（有意边界，非缺陷）

• W<16K 显式窗口下有效输出比 rebase 前收紧最多 2048（W=8192：6144→4096）——镜像底座窗口启发式的代价；
• ≥500K 大窗时压缩输出预留自 TURN_MAX 262144 收敛到声明值，紧急预算线抬高、自动压缩相应推迟；
• 官方端点的未登记新模型仍保持 8192 有意保守（缺行≠放行）；
• operator-owned 未登记模型的输出天花板实质 ≤64K/65_536，无 GUI 途径超过（SavedModel.max_output_tokens 受进程 24K 夹持后仅做向下收紧）。

验证

• cargo check / fmt 全绿；目标测试 6/6（route_limits×2、forkguard_cloud×2+env 版、unknown_cloud、compaction_cloud）
• 反向验证：neutralize 底座 #5461 新臂 → forkguard_cloud_models_defer_output_cap_to_base 红（118784≠62_976），还原复绿
• 底座 route_budget 12/12；fork-guard.sh --fast、verify-public-submodule.sh（r11↔gitlink）、architecture-guard.py、test_ci_gate_policy.py 17/17

[asto18089]

跟进：#367（r11 基线同步）合入 main 后的二次收缩（head ac360ac0）

上一条评论发出后，main 前进了 #367——r11 公开基线同步（gitlink→0d89a31be、verify tag r11、fork-guard 拓扑、Cargo.lock lru 链、fork 文档登记、ci-gate-policy 断言）已作为独立 chore PR 落地，与本分支当时的基线部分完全同源。

已按「脚本文档全取 main」完成二次 rebase 并收缩本 PR 为纯 app 侧功能（3 文件，+208/−9）：

• route_limits_for_model 核心逻辑与全部守护测试（含已发布评论中的六项代修：coding_plan 排除、极小窗 ≥4096 门、CODEWHALE_/DEEPSEEK_ env 守卫、D 分支以真实路由产物钉行为、E/F 新用例）；
• docs/fork-modifications(.en).md 父仓适配行登记本项能力各一句；
• 已从本 PR 移除：gitlink、verify-public-submodule.sh、fork-guard.sh、test_ci_gate_policy.py、Cargo.lock（均以 chore(codewhale): sync r11 public baseline #367 版本为准，本分支不再触碰）。

提交信息按新口径重写。验证复跑全绿：cargo check/fmt、forkguard 全家 26/26、fork-guard --fast、verify-public-submodule（r11↔gitlink）、architecture-guard、ci-gate-policy 17/17。

[asto18089]

Re-review follow-up on the current head e8671f07f (forced update from ac360ac0; tree unchanged except English wording):

1. [P1] The claimed r9 foundation target is stale — resolved. The branch now rides the published baseline: gitlink = 0d89a31be, which is exactly what pinvou-v0.9.5-r11 dereferences to on Pinvou/CodeWhale, and verify-public-submodule.sh pins r11. No private drift commits remain; the foundation part was absorbed into main by chore(codewhale): sync r11 public baseline #367, leaving this branch a pure app-side change (3 files).

2. [P1] Current-main conflicts — resolved. The branch is parented on the chore(codewhale): sync r11 public baseline #367 baseline (4c5b1d642) and GitHub reports MERGEABLE against current main (0af69ed64); the route_limits_for_model region is untouched by feat(browser): add native three-platform browser workspaces #252 and the targeted bridge suite passes on the combined tree.

3. [P2] Collaboration metadata in English — resolved, plus the same rule applied to the diff. Title, description, and the commit subject/body are rewritten in English (subject fix(chat): declare output route fact for uncatalogued models, 49-char description, DCO trailer preserved; scripts/validate-commit-msg.py passes). Going one step further per CONTRIBUTING.md ("Use English for ... code comments ... and diagnostics") and the c2f23a00d precedent: the ~45 PR-added Chinese comment/assertion lines in bridge.rs are translated to English — faithfully, including the operator-owned rationale, the min() downward-merge note, the coding_plan exclusion, the D-case behavior pin, and the F-case window boundaries. Pre-existing localized comments (e.g. the untouched doc-comment lines above route_limits_for_model, the zh fork register) are exempt and left alone; docs/fork-modifications.md stays Chinese as the bilingual register pair's zh side.

Verification on the new head: targeted bridge tests 4/4, fork-guard.sh --fast pass, verify-public-submodule.sh r11 pass, architecture-guard.py pass, test_ci_gate_policy 17/17, cargo fmt --check clean, git diff --check clean.

Ready for re-review.

[zhuowp]

Re-review of e8671f0: the branch is now correctly reduced to the app-side route declaration on the published r11 foundation, the PR metadata is current and English, and no new standalone defect was found in the route-limit semantics.

[P1] Resolve the current-main register conflict before approval. GitHub reports mergeable=false / dirty, and git merge-tree --write-tree origin/main HEAD reproduces a content conflict in docs/fork-modifications.md. Reconcile the bilingual register against current main without dropping either the current inventory or this PR's app-adapter entry, then rerun the combined-tree gates and re-request review.

[asto18089]

Rebased onto current main 794a13d10 (r12 baseline) and pushed as 7912e7741 (force-push; tree shape unchanged: 3 files, +243/−9).

[P1] Register conflict — resolved, and the audit's factual claims were verified locally before fixing. git merge-tree --write-tree origin/main e8671f07f reproduced exactly one content conflict, in docs/fork-modifications.md (the register was rewritten to r12 wording by #371/#375 while this branch carried the r11-era 父仓适配 row; fork-modifications.en.md and bridge.rs auto-merged). The organic resolution keeps both sides:

• zh register: main's r12 inventory (drift/guard rows and the whole r12 search section) is preserved byte-exact — the final diff vs main is exactly one row — and this PR's app-adapter entry is re-anchored into the current row: 「…严格直连模型大小写桥接回归、搜索源设置页引导文案，以及 operator-owned 未登记云端模型（自定义 openai-compatible 端点）的显式输出路由事实声明与官方端点 fail-closed 守护（承 PR fix(chat): declare output route fact for uncatalogued models #216）」.
• en register: the PR bullet lands in the unchanged r11 output-ceilings line, as in the previously reviewed shape.
• bridge.rs: main's feat(browser): add native three-platform browser workspaces #252/chore(codewhale): adopt published r12 baseline (#33 native search, #35 keyless Bing tail) with search-source guidance #375 additions live in disjoint regions; the file's diff is identical to the previously reviewed one modulo line offsets (diff-of-diffs checked).

Combined-tree gates rerun on the new head (CodeWhale gitlink untouched by the PR, resolves to main's published r12 9c5f4f19): targeted bridge tests 7/7 (forkguard_cloud_models_defer_output_cap_to_base, forkguard_cloud_route_output_not_pinned_by_global_env, forkguard_openai_compatible_route_uses_declared_limits, unknown_cloud_model_does_not_gain_a_speculative_route_limit, plus the route_limits / compaction_cloud family), fork-guard.sh --fast pass, verify-public-submodule.sh r12 pass, architecture-guard.py pass, test_ci_gate_policy 19/19, cargo fmt --check clean, git diff --check clean, commit-message validation pass.

One pre-existing main condition observed while testing (not introduced or touched by this PR): cargo test --locked wants member versions 0.8.7 → 0.8.8 in pinvou3-app/src-tauri/Cargo.lock after the #374 version bump — the known stale-lock item; it needs a standalone main-side fix.

PR description's verification section updated for the new head. Ready for re-review @zhuowp

[zhuowp]

Re-reviewed at c02e025a6. The current-main register conflict is resolved, the branch is merge-clean, and the app-side route declaration remains narrowly scoped to operator-owned/custom OpenAI-compatible endpoints while normalized coding-plan entries and official presets stay fail-closed. The explicit configured limit and local-vLLM priorities are preserved, and the focused guard covers the foundation budget path. No blocking finding remains.\n\nThe current Linux rust-test failure is the shared hosted-runner disconnect after a successful compile/link step, not a test assertion; rust-lint, Windows Rust tests, fork/architecture gates, and the other applicable checks pass.