[面板] organize 上线后：/dream-status 的最近 5 条 run 会混进 run_type='organize'（过滤还是标注） #495

触发条件

organizeEnabled 打开、agent 调用 memory_organize 之后。默认关时一行 organize 回执都不会产生（工具不注册）。

事实（对照 main）

• dsh-mneme/src/api.js:1517：const runs = (service.listDreamRuns?.({ limit: 5 }) ?? []).map(...) —— 不分 run_type，取最近 5 条。
• dsh-mneme/src/api.js:1523：run_type: r.run_type ?? "auto" —— 类型是透出给面板的，面板有没有用它是一回事。
• 一次整理产生两行：dryRun 报告一行 + apply 回执一行（回执的 outcome.dry_run_id 指回报告）。也就是说一次 dryRun→apply 吃掉 5 个名额里的 2 个。
• 这是 PR feat(organize): agent 主动整理接口 dryRun -> apply（issue #231） #267 备注 1 里预留的那个决定，原话：「当前没有工具/API 暴露 organize，生产上不会产生 organize 行；等注册工具那批再决定要不要在面板的巩固列表里过滤它」。注册工具的那批是 feat(organize): agent 主动整理接口接上调用入口（memory_organize + organizeEnabled） #496，本条就是它刻意留下的那一半。

待定的是展示口径，不是数据

两条路都能走：

1. 过滤：/dream-status 只列巩固族的行，整理回执另开一个读数。省事，但把「agent 刚刚改过库」这件事从界面上藏起来——而它恰恰是人最该看见的一类改动。
2. 标注：保留混排，面板把 organize 的行渲染成不同标签（报告 vs 落地还得再分开说），同时保证一次整理不要把列表挤空。信息全，代价是面板文案与 run_type 的口径都要动。

倾向 2，理由是这条线一贯的取向是「审计面是证据，不因显示面积而省略」；但这是面板侧的决定，归面板线拍。

为什么不在 #496 里做

lib/client.js 是单写者资源（AGENTS.md），面板线有别的工作在跑；#496 只动 src/ 与 test/。

参考

• 落地：PR feat(organize): agent 主动整理接口接上调用入口（memory_organize + organizeEnabled） #496（分支 feat/231-organize-tool-exposure）
• 上游：issue [Feature] agent 主动整理接口：dryRun 比对报告 → agent 判断 → apply，全留审计 #231、PR feat(organize): agent 主动整理接口 dryRun -> apply（issue #231） #267 备注 1