清单审定在真实部署里没人能推进：需要一个不等于「编辑整条职责」的审批写权限 #116

#107（PR #114）把员工确认 → 主管审定/打回做成了 duly_duty.review_status 状态机，演示能跑通，因为演示账号是平台管理员。在真实部署里，没有任何一个 Duly 权限集能写这个字段：duly_member 对 duly_duty 没有 allowEdit，三个权限集的 writeScope 都是 own。审定流水线在部署环境里是一件摆设。

这不是 #107 漏做，是它刻意没做——两个能打开的口子都会推翻文件里写明理由的决定：

#107 选了 D，我同意——把对象级编辑权放开去换一个字段，正是那种放开之后永远收不回来的过度授权。

真正要决定的

审批是不是一次「普通字段写入」。 如果是，就需要平台的字段级写权限（先量 17.2.0 有没有——权限集 schema 里有没有 per-field write）。如果不是，审定应该是一个独立的动作（有自己的权限位，不经过对象编辑权）——但 app 声明的 action 现在渲染不出来（objectui#7234），所以这条路今天走不通。

所以三条可能的路：

1. 平台有字段级写权限 → 用它，只放开 review_status 和 review_note，A/B 的代价消失。先量。
2. 没有 → 等 objectui#7234，把审定做成 action，权限挂在 action 上。
3. 都不等 → 接受 A（成员能改自己职责节奏）作为已知妥协，写进 AGENTS.md。

我的建议：先做 1 的测量（一张小卡，只回答「平台能不能按字段限制写」），结果决定走哪条。这是安全模型的决定，不是我该替你拍的。

关联：#107、objectui#7234、src/security/permission-sets.ts 文件头。