背景

通知中心 / action badge 可能在没有 active background task、没有 failed card 的情况下继续显示“需要处理”。这会让用户误以为后台处理还没完成，但实际可能只是 pending calendar action、card detail update 或其它 inbox 类项目。

这个 issue 关注的是：拆清通知中心语义，并让清理和过期行为变得明确。

当前判断

当前 pending count 混合了多个来源：

• pending system actions，例如等待用户确认的 calendar/reminder action
• pending clarification requests
• card detail update notifications，例如新评论/新洞察
• 当 failed card count 非零时，额外合成一个 failed-card 入口

这些来源语义不同：

• 有些需要用户立即操作。
• 有些只是信息更新。
• 有些是过期/历史未处理 action。
• 有些是后台失败，不应该被普通“已读/清理通知”误清掉。

由于它们共用同一个 badge 和入口，UI 会让用户误以为仍有后台处理任务需要处理。

产品模型建议

通知中心按语义分区：

1. 后台异常

   • failed tasks、failed cards、failed visible agent runs
   • 操作：重试、查看原因、忽略/标记已解决

2. 待确认动作

   • pending system actions，例如 calendar/reminder proposals
   • 操作：确认、忽略、拒绝、批量忽略

3. 卡片更新

   • card detail updates，例如新评论/新洞察
   • 操作：打开卡片、标记已读、全部已读

4. 澄清请求

   • 需要用户补充信息的 clarification requests
   • 操作：回答、忽略

Badge 语义建议

推荐 badge 只统计真正需要用户行动的项目：

• 后台异常
• 未来 pending actions
• clarification requests

普通 card detail update 不要和“需要处理”共用同一个强提醒计数，或者应作为更轻量的通知提示展示。

过去的 calendar actions 不应无限期维持主 badge。

过期 / 清理策略

System actions

候选策略：

• 未来 calendar/reminder actions：计入主 badge。
• 已经过期的 calendar actions：转成 expired / past_due，或显示在单独的“历史未处理”分区。
• dismissed actions：从通知中心隐藏，但仍可被 schedule/history 使用。

Card detail updates

候选策略：

• 打开卡片后清理对应 update。
• 增加“全部已读”。
• Debugging/reprocess 产生的 card updates 默认静默，或合并成一条“批量重处理完成”。

Background failures

候选策略：

• 不随普通“全部已读”清理。
• 必须显式重试、resolve 或 ignore。
• 失败原因需要保留可查看。

候选方案

方案 A：先做 UI 分组

最快改善体验。把现有来源分区展示，并调整文案和 badge 语义。

方案 B：为 notification row 增加 read/status 语义

长期更正确，适合 card updates 和通知生命周期管理，但需要数据/模型迁移。

方案 C：为 system actions 增加自动过期策略

避免旧 calendar proposal 一直维持 badge。需要清楚区分 expired、dismissed、rejected。

方案 D：把后台健康状态从通知中心拆出去

把 failed tasks/agent runs 放到单独后台健康入口，通知中心只保留用户可读通知和动作。这是更大的产品整理。

推荐：先做方案 A + C；之后再评估方案 B。方案 D 可作为后续更大产品清理。

验收标准

• 通知中心能清楚区分后台异常、待确认动作、卡片更新和澄清请求。
• 主 badge 不再因为普通信息更新而暗示“后台仍在处理”。
• 用户可以批量清理 card-detail updates。
• 过去的 calendar actions 有明确过期或 past-due 策略。
• 后台失败不会被普通通知清理误清掉。
• 测试覆盖 mixed sources 下的 pending count 计算和分区展示。