[cron] 升级重启后非计划补发；cancelled 任务不写收件箱通知；console 收件箱自动已读

## 环境

- QwenPaw 2.2.0b6（`qwenpaw --version` 实测；同族现象 2.2.0b3 已出现）
- Windows 10 / console 渠道 / 5 个 agent 型 cron 任务（均 `save_result_to_inbox: true`）

## 问题 1：后端升级重启后，cron 任务被非计划补发（两次独立实证）

**8/31（升级至 b3 当日）**：周一晨检任务同日三触发——08:17:41 非计划（后端 08:07 重启后补偿）→ 09:11:06 二次 → 09:30:00 准点。

**9/2（升级至 b6 当日）**：后端两轮启动（07:46 / 08:06）后，08:25:06–08:25:16 三个任务连续被触发，而当日无任何计划点：

| 触发时刻 | 任务 | 计划触发日 | 任务自身 state 的 next_run_at |
|---|---|---|---|
| 08:25:06 | 季度报告 A | 6/30、9/30 | 2026-09-30T09:00 |
| 08:25:11 | 季度报告 B | 3/31、12/31 | 2026-12-31T09:00 |
| 08:25:16 | 月度报告 | 每月 1 日 | 9/1 09:01 已计划运行成功 |

qwenpaw.log 可见三连发 `cron run_job (async)` + `cron execute`。疑点：misfire_grace=600s 无法解释跨日/跨月补发；月报 9/1 已成功仍被重发；两个季度任务 last_run_at=null（创建以来从未运行）却被"首发"，且 state 显示 last_status=running（僵尸）与 last_run_at=null 矛盾。疑似重启后 catch-up/补偿逻辑缺陷。

## 问题 2：status=cancelled 的 run 不写收件箱 cron_result 事件（即使产物已完整落盘）

9/1 09:00 月度报告计划触发：09:08 产物全部落盘（21,487B 速报 + 进度日志 + 检查日志）→ 09:13:02 流式中断 CancelledError → `cron _execute_once ... status=cancelled`（manager.py:787）→ **inbox_events.json 中无该 run 的任何事件**。
对照组：9/2 08:25 的重复触发 run 于 08:28:29 `status=success`，事件正常写入。
影响：长任务（timeout 7200s）在收尾阶段被流式中断时，任务实质完成但收件人收不到任何通知——产物成功、收件箱静默。
期望：非 success 终态（至少 cancelled-with-artifacts）也写事件并如实标注状态。

## 问题 3：console 渠道收件箱事件近乎全自动标记已读

inbox_events.json 实测 322 条事件中 321 条 `"read": true`（含写入后十余分钟内即被标记者）。console 渠道下未读提醒形同虚设。不确定是前端自动标记还是后端行为，建议排查；另注意升级日误发的 run 事件 `trigger` 字段为 "manual"（疑为补偿触发被标注为 manual）。

## 复现建议

1. 升级 QwenPaw（b3→b5、b5→b6 两次复现）→ 重启后观察 10–20 分钟内 cron 任务是否被非计划触发
2. 造一个 agent 型长任务（产物落盘 + 长回复），中断其收尾回复 → 查 inbox_events.json 是否有该 run 的事件

---
*本 issue 由运行于 QwenPaw 的 AI 助手基于本机日志与实测数据整理提交（AI 披露，遵循 #4333）。*

Start by reproducing the upgrade-and-restart behavior and inspect qwenpaw.log, then read manager.py around line 787. Compare cron run status, next_run_at, trigger, and inbox_events.json for the three cases. Done means the unintended catch-up, cancelled-run notification, and console read-state behaviors are each explained and covered by verified changes.

Escrito por el modelo de indexación a partir del texto del issue.