[REQ-128][CODE] 把 ActionResult 的 warning 呈现收口到 IPC 包装层 —— 逐调用点写一行的形态已栽三次 #765

大白话

后端把「这次操作有个你该知道的问题」如实报出来了，但用户看不到——
因为呈现这件事是逐个调用点各写一行，谁忘了写谁就静默吞掉。

本期（REQ-128 Phase 2）三次栽在这个形态上，最后一次是审计跑真实 UI 才抓到的。

实测（2026-08-01，alpha-code#698 R3）

ActionResult 的类型定义本来就写着「调用方必须呈现，不得静默吞掉」。
实际枚举下来，六个调用点里只有一个（agent 分支）照做：

第 3 处是闸门逼出来的：先修了其余五处，闸门仍红——从详情页装 package 走确认屏 →
二次 installCatalog，压根不经过 addDirect。只按行号改就会漏掉它。

#698 已把 addDirect 改成单点出口（新增分支默认被覆盖），但那只覆盖了一个函数。

本票要做的：把咽喉挪到 IPC 包装层

呈现不该是每个调用点的责任。真正的咽喉在
packages/ui-mac/src/renderer/extensions/use-extensions.ts 的 IPC 包装层 ——
凡是返回 ActionResult 的调用，warning 在那一层统一呈现，调用点不再各写一行。

⚠️ 这是跨函数重构，#698 的最后一版按边界没做（审计预算已用满，不冒险）。

Development plan

1. 先勘破：use-extensions.ts 里有多少个返回 ActionResult 的包装？它们的调用点各是谁？
   两条独立检索轴（ActionResult 类型使用点 / warning 字段消费点），rg -a。
2. 在包装层统一呈现；删掉各调用点的重复行。
3. 判据不是「我改完了六处」，而是「新增一个返回 ActionResult 的调用点，
   忘了呈现 warning 时会不会红」 —— 咽喉对新成员默认拒绝，枚举对新成员默认放行。

Acceptance and named gates

• 用真 ExtensionHub + 真 ToastViewport 的闸（#698 已建，参照它）：
  给真实成功响应挂 canary，断言它出现在 .a-toast 文本里。
• 新增一条不呈现 warning 的调用点 → 必须变红（这是本票的真正判据，要自己实施一遍）。
• 删掉包装层的呈现 → 现有闸全红。

Out of scope

改 ActionResult 的形状；改后端产 warning 的位置；新的 toast 组件。

出处

alpha-code#698 R3（PR #763）。本期第三次栽在 renderer 半场，值得机制化。