双写事件传播作业 Cursor 已卡死 48 小时以上,未记录任何错误

环境: 自主托管、Kubernetes (EKS)、Helm 图表 langfuse-k8s v2.0.0 Langfuse v4.27.0，从 v3.224.1 迁移到 chart v1 → v2 → app v3 → v4（遵循官方升级指南） ClickHouse 26.4.5（由运维人员管理，3 个副本），PostgreSQL 17.9（RDS），Redis 7.0.7（ElastiCache） 迁移写入模式：LANGFUSE_MIGRATION_V4_WRITE_MODE=dual，已启用历史补齐并成功完成（所有 4 个 background_migrations 步骤都显示“阶段”：“完成”） 问题：双写“事件传播作业”（worker cron，日志为 [DUAL WRITE]，每 ~60 秒执行一次事件传播作业）的 Cursor 已在固定时间戳上卡住 48 小时以上，没有记录任何错误或警告： [DUAL WRITE] 最后处理的分区：2026-09-09 18:57:00 [DUAL WRITE] 没有可供处理的分区（最后处理时间：2026-09-09 18:57:00） /api/health?failIfEventPropagationStuck=true 端点没有标记此为卡住（“卡住”：false），但报告： json "propagationDelaySeconds": 179039 （~49.7 小时） 已确认不是原因：源 ClickHouse 分区（跟踪/观测，按月分区）正在积极接收新插入数据 - 通过 system.parts（最近修改时间）确认。 不是 pod 局部状态问题 - 该 worker pod 重启后，Cursor 值保持相同（新 pod，相同卡住时间戳）。 与 background_migrations（Postgres）无关 - 该表只跟踪一次性的历史补齐步骤（已完成）；这是一个独立的、正在进行中的机制。 48 小时内，worker 日志中没有与 propagat|dual 相匹配的错误或警告。 影响已测量：17 个跟踪和 191 个观测，在卡住时间戳之后创建，尚未反映在 events_full/events_core 中。 向团队提出的问题：存储后端保存了该作业的 Cursor/水印（我们缺少的 Postgres 表、Redis 关键字或其他内容），是否存在支持的手动检查/重置方式，而不会对迁移状态造成风险？