feat: 制品库支持按需分库 #4125

[zacYL]

No description provided.

[cnlkl]

主要问题

CATCH_UP → VERIFY/READY → DUAL_WRITE 之间存在写入丢同步窗口
当前 CATCH_UP 安静一段时间后就进入 VERIFY，之后 VERIFY、READY 阶段不再持续消费 Change Stream。
这期间业务仍只写 Default，如果再发生写入，Heavy 不会自动补上。开启双写时也没有看到“最后追到 dualWriteStartAt”的逻辑。

enableDualWrite 缺少最终追平动作
文档要求 CATCH_UP 追到 catchUpEndAt = dualWriteStartAt，但当前实现只是检查状态和门禁后推 Consul、置 DUAL_WRITE。
所以 READY 停留越久，数据不一致风险越高。

双写期存在“主库写成功、补偿未落库”宕机窗口
node 双写期是 Heavy 主路径，Default 副路径。
如果 Heavy 写成功后，进程在写 Default 或记录补偿任务前宕机，可能出现 Heavy 有、Default 没有、补偿队列也没有记录。后续只能靠对账发现，补偿队列本身兜不住这个窗口。

VERIFY 的自动修复能力不完整
当前少量分片不一致时会重新从 Default 扫描并 upsert 到 Heavy。
这能修“缺失/旧版本”，但不能清理 Heavy 多出来的僵尸数据。如果不一致原因是 Heavy 多数据，单纯 upsert 不会解决，可能反复 VERIFY 或最终进入 REBUILD_REQUIRED。

REBUILD_REQUIRED 没有产品化恢复流程
当前进入 REBUILD_REQUIRED 后 Job 只打日志等待人工介入。
没有 rebuild API，也没有自动清理 Heavy、重置断点、重新捕获 Change Stream 的流程。实际恢复需要人工改状态表和清数据，操作风险较高。

次要但需要确认的问题

Change Stream 按 fullDocument.projectId 过滤 update/replace
如果 projectId 是严格不可变字段，没问题。
如果存在跨项目移动或更新 projectId 的路径，旧项目迁移流可能看不到这类变更，需要额外处理。

READY 没有过期/新鲜度校验
READY 可以停很久，但开启双写时没有检查最近一次 VERIFY 时间，也没有重新追平。建议加 READY 最大有效期或开启双写前强制 final catch-up。

CATCH_UP 的 resumeToken 不是每个事件后立即持久化
当前是窗口结束后保存 token。宕机后可能重复回放一段事件。现在 upsert/delete 基本幂等，所以可接受；但以后如果加入非幂等操作，需要特别小心。

REBUILD_REQUIRED 无法通过现有 start 流程直接重启
start 只允许 PENDING/INIT_FAILED，REBUILD_REQUIRED 需要人工改状态才能重新开始。

[tencentblueking-adm]

All committers have signed the CLA.