测试服务器每小时告警一次「friday DW 数据滞后 37 小时」,是误报:
friday 是 **push 宿主**,数据由宿主主动推,sync_logs 的 cursor_before/after
按设计恒为 null,根本没有游标可推进。它之所以有游标,是历史上误跑过一次增量、
留下一条 fetched=0 的 incremental_bundle 记录,游标就永久停在 2026-07-30T10:00Z。

而同期 friday 正常 push 了 614 批 10.79 万行(含新接的跟进闸字段),数据流毫无问题
—— 拿"游标多久没推进"衡量 push 宿主,是**指标本身用错了**。

危害不只是烦人:该告警**永不自愈**(游标不可能再推进),每小时响一次,
最终把真告警淹掉 —— 一个永远在响的黄灯,看的人很快就不看了。

改法:遍历宿主时按 manifest 是否声明 sql_source 短路。
  - 判据选 sql_source 而非 auto_sync:前者与 files **二选一**(manifest.schema 原话),
    是"数据从哪来"的定义即摄入模式本身;auto_sync 只是"要不要自动跑",可临时关,
    跟模式是两回事。
  - 短路放在「还没跑过增量(无 cursor)」那条 warn **之前** —— 否则 push 宿主
    只是换个姿势继续刷日志。
  - getHostOpsConfig 读不到 manifest 时 hasSqlSource 兜底 false:宁可不报,
    也不要对着未知宿主刷告警。

回归闸 tests/dw-lag-monitor-scope.spec.ts(5 项),已验证去掉守卫会报 2 项失败。

注:push 宿主的健康度应看「距上次成功 push 的时长」,是当前的监控盲区
(FRIDAY 断推三天也不会有任何告警),本次按要求不做,单独评估。

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