sync-lock-reap.spec.ts 在整套 jest 并行跑、机器同时有重负载时间歇失败:
该套件平时约 5 秒,失败时耗到 68 秒。

根因不是逻辑错,是判据两端取的时间**不同源**:
  · 界   = PROCESS_STARTED_AT,模块加载时刻 T0
  · 造行 = `new Date(Date.now() - 1000)`,用例执行时刻 T0+Δ 减 1 秒
要判成僵尸需要 Δ < 1s;负载高时模块加载到用例执行的间隔超过 1 秒,
行反而落到界**之后**、不再算僵尸 → findMany 空 → updateMany 没被调
→ `updateMany.mock.calls[0][0]` 直接抛。

修法:把时间界作参数注入 reapStaleRunningLocks(默认仍是 PROCESS_STARTED_AT,
**生产行为一字未变** —— onModuleInit 那个调用点不传参),测试用固定基准
构造 before()/after(),全程不碰真实时钟。

顺带补一条边界断言:startedAt >= 界的行(并存 CLI 的真锁)连 updateMany
都不该发 —— 原来只锁了 where 用 lt 不用 gte,没锁住"真的不碰"这个行为。

⛔ 没有用调大 jest timeout 掩盖:那只是把失败推后。

验证:并行跑 `next build` 制造负载,连跑 3 次整套 857 测试全绿。

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