补充 Pebble spool Phase B 崩溃恢复与目标端一致性验证

## 背景

#987 已完成 Pebble spool 的持久化、重开恢复和两阶段清理补强。当前验证已经覆盖 spool 持续写入时 `kill -9` 后的本地数据保留、旧 spool 重开、从 durable `last_write_ts` 续读，以及 debug executor 下的完整生命周期。

仍有两项需要独立补充验证：

1. Phase B 清理过程中两个持久化状态窗口的故障注入与重启恢复。
2. 使用真实 target 验证 at-least-once 重放后的最终 count/checksum 一致性。

## Goal

证明 Pebble spool 在 Phase B 清理窗口发生进程崩溃时可以安全重启并收敛，同时确认可能的重复 apply 不会造成目标端最终数据不一致，也不会产生 oplog 空洞。

## Scope

### Phase B 故障注入

分别在以下窗口硬终止 collector，并使用同一配置重启：

- finish marker 已持久化、本地 spool 尚未删除；
- 本地 spool 已删除、远端 `OplogDiskQueue` 尚未清除。

每个窗口需要核对本地 spool 目录、远端 checkpoint、queue name、finish timestamp、重启日志和最终清理结果。

### 目标端一致性

- 使用可控的真实 source/target 数据集和 direct executor；
- 覆盖正常完整生命周期，以及 spool 写入或回放期间的受控 `kill -9`；
- 等待链路收敛后，对 source/target 执行 count 和 checksum 对比；
- 记录 at-least-once 重放产生的重复 apply 现象及其最终幂等结果。

## Implementation Scope

- 补充可复现的故障注入步骤、必要的测试辅助和脱敏验证记录；
- 如验证暴露实现缺陷，先记录明确复现和影响，再在本 issue 范围内评估是否需要代码修复；
- 不改变现有配置键和默认行为，除非验证证明当前语义无法满足验收标准。

## Out of Scope

- change stream spool；
- 旧 `go-diskqueue` 或 Pebble schema v1 的自动迁移；
- 生产环境部署与长期性能压测；
- 与 #987 无关的 checkpoint、executor 或 MongoDB 兼容性改造。

## Acceptance Criteria

- 两个 Phase B 崩溃窗口均完成一次受控故障注入和同配置重启；
- finish marker 已持久化但 spool 尚未删除时，重启后能够继续清理并最终清除 queue metadata；
- spool 已删除但 queue metadata 尚未清除时，重启不会尝试重放已删除 spool，清理能够幂等完成；
- 重启后 collector、Metrics 和 checkpoint 均继续推进，无相关关键错误；
- 真实 target 在链路收敛后与 source 的 count/checksum 一致；
- 结果明确区分“可能重复 apply”与“不得产生 oplog 空洞”，并记录实际观察；
- 验证命令、环境边界和脱敏结果回写到本 issue。

## Dependencies / Blockers

- 依赖 #987 的最终实现；
- 需要可控的 source/target MongoDB 环境、collector 进程终止权限和安全的测试数据集；
- 若环境暂不可用，保留为环境依赖验证，不以本地单元测试替代。

## Verification Entrances

- `go test ./collector/spool -count=1`
- `go test ./collector -run 'Test.*(Checkpoint|Persister)' -count=1`
- 受控 collector `kill -9` 故障注入；
- source/target count 与 checksum 对比；
- checkpoint、spool 目录、Metrics 和错误关键字联合核对。

## Documentation / Configuration Sync

- 若验证结论改变恢复保证或适用边界，同步更新 #987 的兼容性与升级说明；
- 若配置语义没有变化，不新增配置项，仅在本 issue 中记录验证结论。

## Related

- #982
- #987