docs(skills): pm-dispatch 探活规程扩为五条 —— 定时器先挂 + 批量在飞期 ≤45 分钟巡检

.claude/skills/pm-dispatch/SKILL.md

@@ -1111,7 +1111,7 @@ attached.
 下面的停摆纠偏处理「带任务中状态的通知到了」;这一条处理更隐蔽的另一半:
 **通知根本不来**。宿主进程重启会把运行中的 subagent 连同其完成通知一起
 静默杀掉 —— 2026-08-05 实测,五个「在飞」dev 里三个(#5050/#5515/#5483)
-已死数小时,批次视图仍显示 5/5,实际吞吐 2/5,零信号。规程三条:
+已死数小时,批次视图仍显示 5/5,实际吞吐 2/5,零信号。规程五条:
 
 - 每次巡检(定时器唤醒、轮间隙)对**每个已派发且尚无远程分支/PR** 的
   dev 发一次状态询问(SendMessage,措辞「回一段简报后继续干活」,不改变
@@ -1122,6 +1122,17 @@ attached.
   优先用它;resume 不可用时才走接手协议。
 - 判据永远取正向证据(远程分支、PR、报告、探活回包),⛔ 绝不把「还没
   收到失败通知」读作「还在跑」。
+- **定时器重挂是每次巡检的第一动作,不是最后一个**(维护者 2026-08-06
+  授权)。巡检执行到一半被打断(穿插提问、事件风暴、会话中断)时,排在
+  末尾的重挂会整个丢失,守夜链就此断裂 —— 2026-08-06 实测:一次漏挂让
+  四连灭批静默了 ~100 分钟而不是探活门槛设计的 ≤45 分钟。先挂后查,链条
+  对中断免疫;挂错了间隔可以在本轮末尾用 delete_trigger + 重挂修正,但
+  「没挂」无法被本轮以外的任何机制补救。
+- **批量在飞期间,主巡检间隔不得长于 45 分钟**(同一授权)。探活门槛是
+  45 分钟,巡检间隔一旦超过它,门槛就成了写在纸上的数字 —— 最坏情形下
+  一个派发后即死的 agent 要等到下一轮巡检才被发现,静默窗口 = 巡检间隔,
+  而非门槛值。在飞清零的待命期可放宽到 60-70 分钟;有任何 dev 在飞即收紧
+  回 ≤45,灭批频发期(如宿主重启风暴)进一步压到 20-30 分钟。
 
 **A stalled subagent is this half's most common failure, and it never
 self-heals.** When a dev stops mid-task reasoning that "a background watcher will