现状:sync-incremental.scheduler 不注入 AlertService。轮次失败只 logger.error
就吞掉(`:38` 注释「跑失败:log ERROR 不抛」),唯一出口是次日 09:07 的每日健康
报告 —— 最坏晚 24 小时。09-04 生产宕 11.8 小时全程零告警,有这一份原因。

而刚加的 compose mem_limit(8g)会把下面这条路径变成常见路径:
  容器被 SIGKILL → 轮次失败 → HTTP 30 秒内恢复 → 外部探针一路绿
即**系统在稳定地失败,而所有指示灯是绿的**。不补这三条,新加的兜底反而
制造了一种更隐蔽的故障。

三条信号:
1. 回收到僵尸锁 → warning。这是「上一轮没正常终结」的**唯一确定性信号**,
   比"轮次失败"更早更准:失败可能只是网络抖动,留下僵尸锁则意味着进程被
   外力打断、没走到 finally。正文直接给 CONSTRAINT_MEMCG 的查法,并写明
   别看 docker inspect 的 ExitCode(restart:always 下那是重启后那条命)。
2. 轮次抛异常 → critical,带错误原文。
3. 套圈跳过 → warning。这是 08-29 雪崩的前兆、也是 09-04 的中间态 ——
   当时 11.8 小时里每轮都在这里 return,防套圈闸救了系统却**吞掉了症状**。

告警统一走 alertSafe:推送失败绝不能反过来打断同步。

测试:5 个新用例,并做了变异测试 —— 逐条拆掉告警 / 拆掉 try/catch,
四次变异全部被咬红,不是走过场的绿。全量 1975 passed。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>