🔴 agent 三套模型不收敛：能建出来的 agent 要么进不了 chat 编制，要么没有真实指令

## 发现经过

另一条并行的端到端测试会话（专测 agent/skill 新建与导入全路径，SHA `d1dd5adc`）实测发现，我已独立核实全部结论。

## 核心问题：agent 相关有三张互不 JOIN 的表，产品代码没有任何路径同步写其中两张

- `agents` / `agent_versions`（手写新建走这条，`createAgent` #617 + 自助发布 #660）
- `capability_listings`（`kind='agent'`，chat 编制唯一认的合法性判据，#619 收敛的落点）
- `org_agents`（遗留表，#619 已收敛掉）

**结果**：
- 走 `createAgent` + 自助发布建出来的 agent，能拿到真实 `201`，但**永远进不了任何 chat 线程编制**（`AGENT_OUT_OF_SCOPE`，编制判定只认 `capability_listings`）。
- 走「能力目录」（admin `/admin/agent` 页的 `POST /capabilities/mutate`）建的条目，能进编制，但没有真实指令/执行链路——发消息报 `422 AGENT_NOT_FOUND`。
- **两条路径都能跑，但拼不出一个真正可用的 agent。**

`apps/api/tests/chat/agent-roster-capability-convergence.test.ts` 头注自己写死了这个缺口：

> ⛔ 本文件不证明"选中后 chat 里真的能调用"——那半段依赖 #617（`createAgent` 全仓零 controller...）。#617 落地后要回来把这两半接上，实测一遍完整链路（issue #619 第三条要求）。

**#617 已于此前关闭，但这句"回来接上"从未兑现。**

## 次要问题

1. **Agent 的双人评审门禁前端零挂载**：`decideAgentPublish`（域层 `apps/api/src/domain/agent/publish-review.ts`）与 skill 的双人评审对称完整，但 `grep -rln "submitAgentForReview|agentPublish|agent-review" apps/web`（源码，非构建产物）零命中。用户唯一能走的发布路径是无监督的「自助发布」（`self-publish.ts`）——这是"没做"不是"没测"，且与 skill 侧的治理标准不对称。
2. 同一个 `/admin/agent` 页面有两个都叫"新建 Agent"的按钮，分别写 `agents` 表和 `capability_listings` 表，互不关联，界面上看不出区别，用户会随机踩中上述任一条死路。

## 与 #624 的关系（需要重新核实，不是指控）

#624（P0 epic，全链路验收）2026-08-17 关闭时的证据是 `core-loop.spec.ts` 42/42 全绿，其中步骤 8b"agent 真的执行并产生恰好一条回复"通过。但按上述发现，产品代码里没有任何路径能让一个 agent 同时具备"可被编制选中"+"可执行"——**只有测试环境的 seed 脚本手动缝合过**这两张表。

这很可能意味着 `core-loop.spec.ts` 的绿是靠 e2e 自己的 seed 脚本人工缝合了一条产品里并不存在的路径，测试通过但不代表真实用户能走通。建议重新审视 #624 的关闭证据是否需要标注例外，而不是直接重开（42/42 绿本身没有造假，只是覆盖面有盲区）。

## 对比：skill 侧做对了

GitHub 导入 → 双重评审门禁 → chat 挂载全链路真实打通，且"无完全新建入口"是明确的产品设计决策（测试用例名字直接把它当断言写死），不是缺陷。agent 侧应该收敛到同一治理水位。

## 要求

1. **模型收敛**（主线）：确定 agent 的单一权威写入模型（参照 #619 对 skill 侧 F190 的收敛先例：`POST /skills` 冻结为唯一权威模型 A），把 `createAgent`/自助发布路径与 `capability_listings` 路径接通，或者废弃其中一条。
2. **评审门禁前端挂载**（独立验收条目，不要和 1 混在一起）：把已存在的 `decideAgentPublish` 接上 UI，agent 发布不再是无监督自助发布。
3. **界面消歧**（独立验收条目）：`/admin/agent` 页的两个"新建 Agent"按钮要么合并要么明确区分语义。
4. 复核 #624 的 42/42 绿证据是否需要为这条盲区补一个已知例外说明。

## 相关文件

- `apps/api/tests/chat/agent-roster-capability-convergence.test.ts`（#619，头注承诺未兑现）
- `apps/api/src/domain/agent/publish-review.ts` / `self-publish.ts`（评审门禁域层，零前端消费）
- `apps/api/src/interface/controllers/agent-publish.controller.ts`
- migration `0032-f110-ai-team-panel.sql`（`org_agents` 头注："占位目录"）
- `apps/api/scripts/seed-fullstack-smoke.ts`（手动缝合 agents/capability_listings 的地方）
- `apps/web/e2e/core-loop.spec.ts`（#624 关闭证据，步骤 8b）

## 相关 issue

#617（已关，createAgent controller）、#619（已关，roster 收敛前半段，测试头注承诺后半段）、#660（已关，自助发布路径）、#624（已关，全链路验收 epic，本 issue 可能是其证据盲区）

Start with apps/api/tests/chat/agent-roster-capability-convergence.test.ts, then inspect the agent publish files, agent-publish.controller.ts, migration 0032-f110-ai-team-panel.sql, and the seed and core-loop files named in the issue. Done means the chosen agent path supports both roster selection and real execution, the review flow is mounted in the UI, the two admin creation actions are distinguishable, and regression coverage documents the #624 evidence boundary.

Written by the indexing model from the issue text.