docs(workbench): clarify active notification counting

docs/operational-notification-routing.md

@@ -1,13 +1,13 @@
 # 异常处置通知路由
 
-“异常处置”只展示需要当前用户判断、授权或处置的活动事项。通知表仍是用户收件箱，不替代 `domain_event_log`；列表同时按通知生命周期、当前用户权限和已读状态过滤。
+“异常处置”只展示需要当前用户判断、授权或处置的活动事项。通知表仍是用户收件箱，不替代 `domain_event_log`；Header 列表按通知生命周期和当前用户权限过滤，不因用户已读而隐藏尚未解决的事项。
 
 通知存在两个互不替代的状态维度：
 
 - `lifecycle_status=active|resolved` 保存在通知文档中，表示对应业务事项是否仍需处理，是项目共享状态。
 - `status=unread|read` 由 `operational_task_notification_reads` 按用户计算，只表示某个用户是否看过。
 
-新通知保存 `subject_type + subject_id`，明确关联任务、Run、访问申请或动作。访问申请审核、动作审批、外部协同恢复、任务重试和人工材料补充，会在更新权威业务状态的同一事务中把对应通知改为 `resolved`，并追加 `operational.notification.changed`。Header 只接收 `active` 通知；已解决通知不会因为某个用户尚未阅读而继续计数。
+新通知保存 `subject_type + subject_id`，明确关联任务、Run、访问申请或动作。访问申请审核、动作审批、外部协同恢复、任务重试和人工材料补充，会在更新权威业务状态的同一事务中把对应通知改为 `resolved`，并追加 `operational.notification.changed`。Header 只接收 `active` 通知；活动事项被标记为已读后仍保留并计数，直到权威业务状态将其解决。已解决通知不会因为某个用户尚未阅读而继续计数。
 
 共享生命周期事件使用 `operational_notification` 聚合；用户点击已读使用 `operational_notification_read` 聚合，聚合 ID 为 `notification_id:user_id`。这样项目共享的解决状态与每个用户的已读修订不会占用同一聚合版本。外围来源撤销时，尚未提交的动作审批、访问审批和任务级待办一并解决；已经提交或结果未知的外部动作仍保留只读回执核对入口。
 
@@ -38,6 +38,6 @@
 
 本次实际执行结果：删除 16 条普通生命周期通知，保留 2 条旧 `action_pending` 审批通知，活动业务告警仍为 0 条，并写入 `event_seq=39` 的批量失效事件。通知表和用户已读表的迁移前逻辑备份位于 `/home/zhifu/TJWaterBackups/notification-routing-20260924-gZvjsn/tjwater_v2-notifications-before-020.json`，SHA-256 为 `046d6c3a0888b981791f3f39ee1972f304aab18a7e6af035da742c069b97a369`。系统缺少 `pg_dump` 客户端，因此本轮没有生成新的整库 custom dump；上一轮整库备份未被覆盖。
 
-`022_operational_notification_lifecycle.sql` 带有 `current_database()='tjwater_v2'` 硬门禁。实际执行后，2 条旧审批通知均已关联到动作：仍为 `pending/not_submitted` 的 1 条保持 `active`，已经 `approved/succeeded` 的 1 条变为 `resolved`；活动未读查询只返回前者。迁移写入批量失效事件 `event_seq=79`，并更新通知文档列注释。迁移前逻辑备份位于 `/home/zhifu/TJWaterBackups/notification-lifecycle-20260924-tLsVeI/tjwater_v2-notifications-before-022.json`，SHA-256 为 `09df5efd2c748536752eaf0df94ad455d88458bb99866ed2163d8a0db56979ea`。其他 BizDB 未执行；扩展仍需维护者明确确认。
+`022_operational_notification_lifecycle.sql` 带有 `current_database()='tjwater_v2'` 硬门禁。实际执行后，2 条旧审批通知均已关联到动作：仍为 `pending/not_submitted` 的 1 条保持 `active`，已经 `approved/succeeded` 的 1 条变为 `resolved`；活动事项查询只返回前者，其个人已读状态不改变活动生命周期。迁移写入批量失效事件 `event_seq=79`，并更新通知文档列注释。迁移前逻辑备份位于 `/home/zhifu/TJWaterBackups/notification-lifecycle-20260924-tLsVeI/tjwater_v2-notifications-before-022.json`，SHA-256 为 `09df5efd2c748536752eaf0df94ad455d88458bb99866ed2163d8a0db56979ea`。其他 BizDB 未执行；扩展仍需维护者明确确认。
 
 历史通知本身没有业务对象 ID。回填只在任务内恰有一个候选动作或访问申请时建立关联；存在多个候选时保持 `active` 并关联任务，不按时间邻近关系猜测，也不会自动隐藏。后续由人工核对或专门迁移处理这类歧义数据。新写入始终携带精确 `subject_id`，不受此限制。

docs/workbench-database-rollout.md

@@ -18,7 +18,7 @@
 
 后续数据库变更默认只写入 `tjwater_v2`。其他项目保持现状，必须等 `tjwater_v2` 验证通过并由维护者明确确认后，再逐库扩展。禁止把“所有活跃项目”作为写操作的默认范围。
 
-通知生命周期迁移 `022_operational_notification_lifecycle.sql` 只修改现有通知 JSON 文档与列注释，不新增表或物理列。脚本带物理数据库名硬门禁；先在 `tjwater_v2` 核对待审批通知仍为 `active`、已审批通知变为 `resolved`，并验证 Header 只统计活动未读项。未取得维护者确认前，不向其他 BizDB 应用。
+通知生命周期迁移 `022_operational_notification_lifecycle.sql` 只修改现有通知 JSON 文档与列注释，不新增表或物理列。脚本带物理数据库名硬门禁；先在 `tjwater_v2` 核对待审批通知仍为 `active`、已审批通知变为 `resolved`，并验证 Header 统计所有当前用户有权处理的活动事项。已读只表示用户看过，不能隐藏尚未解决的事项。未取得维护者确认前，不向其他 BizDB 应用。
 
 ## 变更顺序