test(capability): include external evidence research in registry smoke

[huangruiteng]

Summary

• include the built-in external-evidence-research capability in the exact-order extension registry smoke
• restore the extension-runtime premerge canary on current main

Validation

• python examples/capability-extension-registry-smoke.py
• loopx check --scan-path examples/capability-extension-registry-smoke.py
• loopx canary premerge --from-git-diff (11/11 selected checks passed; no failures or manual holds)

Boundary

This is a one-line durable smoke alignment for a capability already shipped on main. It changes no runtime, schema, authority, permission, or public behavior. Generated uv.lock and local state are excluded.

[huangruiteng]

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)

动机

external-evidence-research 已经作为内置 capability 进入生产目录，tests/capabilities/test_capability_extension_registry.py 的单元期望也已经包含它；但公开的 capability-extension-registry-smoke.py 仍停留在旧列表，因此 extension-runtime premerge canary 会在真正进入 extension compose/install/doctor 路径之前，因为基线列表少一个 id 而失败。

这个 PR 修的不是产品目录，而是一个已经漂移的、仍有实际消费者的 durable smoke。目标边界成立：让 smoke 继续准确约束当前 built-in catalog，同时不改变 capability 顺序、provider、schema、权限或运行时行为。

改动思路

实现直接把 external-evidence-research 插入 smoke 的精确顺序期望，位置与 loopx/capabilities/catalog.py 的权威 BUILTIN_CAPABILITIES 以及现有单元测试一致：位于 connector-registry 之后、reliability-diagnostics 之前。

我也检查了是否应该删除这个精确列表。结论是不应删除：单元测试验证 in-process catalog，公开 smoke 则通过真实 CLI 继续覆盖 extension manifest composition、bundled install、doctor 和 provider readiness。两者是互补覆盖；把 smoke 改成宽松包含检查会让目录顺序漂移失去预警。

具体改动

精确 head 05cc04c0e52ebb4e0004e87f63ba70196fc523be 只改一个文件、增加一行；与上一 head 的 range-diff 显示 patch 完全一致，本次重新在新 base 上执行了验证：

• examples/capability-extension-registry-smoke.py 的 built-in id 列表增加 external-evidence-research。
• 没有生产代码、文档、生成文件、manifest 或持久状态变化。

我执行了：

• PATH=$PWD/.venv/bin:$PATH .venv/bin/python examples/capability-extension-registry-smoke.py：通过，输出 capability-extension-registry-smoke: ok；
• .venv/bin/loopx --format json check --scan-path examples/capability-extension-registry-smoke.py：8 项检查、0 error，public boundary clean；两条 warning 来自无关 Goal 的既有 projection gap；
• git diff --check：通过；
• capability packet 的最终远端状态为 2/2 checks success。

我还做了 bounded existing-coverage 与 same-author batch scan：现有单元覆盖没有替代这个 CLI/lifecycle smoke；作者的其他 open PR 中也没有同形状的一批一行 smoke PR，因此不存在批量刷小改动或重复脚手架问题。

对主干的风险

主要风险是精确顺序 fixture 的维护成本：以后新增或重排 built-in capability 时，这个 smoke 会再次失败。但这里的失败是有意的目录漂移守卫，而且它还能防止后续 extension lifecycle 断言在错误基线上运行。这个一行修复与生产权威完全一致，没有把当前输出反向当成新的产品规则。

PR 已重基到当前 main；本次审查绑定新的 exact head，权威 catalog、现有单元期望与 smoke 新列表三者一致，touched smoke/边界扫描均通过，最终远端 Sign-off 与 dependency-review 也都成功。本 review 不改变 merge authority。

我的整体评价

没有 blocking finding。这个修复很小，但不是无价值的小步：它恢复了一个真实 premerge canary，并保留了 CLI + extension lifecycle 的端到端覆盖。代码量、问题规模和回滚边界匹配，也没有引入新的重复 fixture。

结论为 APPROVE。由于这是 author-owned PR，GitHub 无法记录 formal self-approval，所以以 COMMENTED exact-head review 记录结论。

English verdict: APPROVE - exact head 05cc04c; the rebased one-line patch is range-diff identical to the prior head, matches the authoritative built-in catalog, restores the real CLI/extension-lifecycle canary, passes the touched smoke, public-boundary scan, diff check, and final Sign-off/dependency-review checks, and introduces no runtime or contract change.