refactor(kernel): loop 扩展面收成闭包 + 插件可自带挂载点（capability 三处撞名收敛）

[fujiwarazz]

两个提交，一条线：先把 loop 的扩展面收干净，第三方才挂得上去。

---

提交 1：loop 的扩展面收成闭包

loop 之前拿的是 { mounts: MountRegistry, hooks: HookRunner }，于是多知道两件不属于它的事：

1. 有两套扩展机制，还得自己排先后
2. 同一时机可能有多个订阅者——MountRegistry 是注册表，「合并策略」跟着进了 loop 的词汇表

turn:end 那段最明显：Stop hook 与挂载点谁先跑、急停凭什么压过续跑，全写在循环里。那些是组合规则不是循环逻辑。

改成 LoopExtensions——一个时机一个闭包，签名里没有任何注册表类型。createLoopExtensions(mounts, hooks) 是 harness 侧唯一决定先后的地方。

与 P2.7 撤掉的那次不是一回事：那次把 Stop hook 包装成 mount 能力，否决权因此受制于注册顺序；这次两套机制在 harness 里仍是两套、语义各自保留，只是对 loop 的呈现统一了。判据：合并之后「用户能不能拦住 agent」还取不取决于注册顺序？那次取决，这次不取决。

---

提交 2：插件可自带挂载点

a) 命名收敛

「capability」在仓库里指三样东西，讨论时永远要先问「你说的是哪个」：

保留 / 改名
✅ 保留	CapabilityProvider	插件契约，与 cap-* 包名一致
改名	kernel/src/capabilities/ → kernel/src/policies/	port→mount 适配器
改名	xxxCapability → xxxPolicy（7 个）
改名	MountedCapability → MountBundle

b) PluginModule.mounts(instance, ctx)

迁移前第三方只能供工具与 hook 订阅，挂载点是够不到的——要挂上去得改 kernel 的装配根，而第三方改不了核心代码。于是能力市场只能卖「替换既有 Port 的实现」，卖不了「新增一个挂载策略」。

现在一个「带自定义工具的领域插件」一个包就够，manifest 加一行，核心代码一行不动：

export function create(ctx) { return new AnalyticsProvider(); }  // getTools() 给工具
export function mounts(instance, ctx) {                          // 自己声明挂在哪
  return [{ name: "analytics:context", mounts: [
    { at: "session:start",   run: async () => ({ additionalContext: "<analytics>…</analytics>" }) },
    { at: "context:prepare", run: async () => ({ append: [note] }) },
  ]}];
}

kernel 用 splitPluginMounts() 按作用域拆进会话级 / run 级两个注册表。插件挂载恒定排在内置之后——context:prepare 是 concat 语义、拼接顺序模型可见。

为什么放在 PluginModule 而不是 CapabilityProvider 上

因为想挂载的不只是插件。判据：Port 的方法签名有没有把调用时机钉死？

Port	钉死了吗
ModelRouterPort.route(payload) / CostMeterPort.onLLMCall / ToolResultCachePort.get	✅ 适配器机械，留装配根
MemoryPort.recall(query)	❌ 没说何时调、结果去哪

于是 memoryRecallPolicy 从 kernel 搬进了 @helios/memory-fs：session:start + <memory> 标签那套是 MEMORY.md 这一派的策略，换成 mem0（每轮带 query 检索、结果作消息、turn 结束抽取）一条都用不上，还会在 session:start 白调一次 recall。

---

护栏

覆盖	位置
合成规则本身（7 例）	test/unit/loopExtensions.test.ts
loop 边界不许再破（3 例）	test/unit/agentLoop/loopExtensionSurface.test.ts
插件挂载 + splitPluginMounts（7 例）	test/plugin-mounts.test.ts

边界那条用「读源码查 import」的笨办法，因为它坏掉不会有任何行为症状：谁在 loop 里加一行 hooks.runXxx()，测试全绿、agent 照跑，只是边界又没了。

六处变异全部命中：去掉急停 early return / 忽略 hadToolUse / loop 重新 import HookRunner / 不注册 run 级插件挂载 / 不注册会话级 / 清空作用域清单。

行为等价的主要证据是断言一字未改：expect(prefix).toContain("<memory>\nprobe:default\n</memory>") 原样通过，改的只有 fixture。顺带发现「召回为空时不注入空标签」那条变成了空转（不装插件自然没标签），已改成装一个「会声明挂载、但召回返回空串」的插件才真的测到空分支。

eval set 21 → 24

新增分层/依赖方向类：判据在 README 的架构约定里而不在代码里，每个文件单看都自洽，考的是「会不会先去找规矩」。

回归

• pnpm typecheck 退出码 0
• npx vitest run 883 passed（+17）
• 真机 eval 8/8：readonly 24/24，六个专项各 3/3