Polars scan_delta 按时间过滤，漏掉毫秒末尾的记录

同一份 Delta 表，先完整读取再过滤能找到 00:00:00.123456，换成 scan_delta(...).filter(...).collect() 却没有这行。若日志中该文件的最大时间写成 00:00:00.123，要检查读取器是否把毫秒截断统计误当成精确上界。

在 Polars 2.0.0 与 deltalake 1.6.6 的组合中，会出现这项读取回归。Delta 协议允许时间戳文件统计截断到毫秒；数据文件中的微秒没有因此消失。读取器若据此认定文件所有值都不大于 .123000，便会错误跳过实际含有 .123456 的文件。

先核对文件裁剪，不修改业务时间

等值、>、>= 等需要比较最大值的谓词都可能漏行。增量读取的 ts > last_watermark 尤其需要注意：任务正常结束、没有异常，也不代表水位线之后的数据已经读全。

保留同一个 Delta version、输入表路径、字段时间单位和时区，再比较两条读取路径。查看已有诊断输出中是否出现“跳过全部文件”之类的统计裁剪信息。先完整读取再过滤的对照会增加内存与 I/O，必须在容量可控的数据或隔离副本上进行，不能直接把超大表全读入生产进程。

不要给业务时间统一减一毫秒或截断为毫秒来凑出一致结果。这样会改变筛选边界、排序和增量水位线的含义。日志统计的保守边界应由读取器处理，源时间仍应保留真实精度。

2.1.0 已在统计层扩宽上界

Polars 2.1.0 会按字段物理单位将时间戳最大统计扩宽一毫秒，包括嵌套结构中的时间字段；溢出时将统计视为未知，而不是回绕。它扩宽的是文件裁剪边界，不是给每条业务时间加一毫秒，最终行级谓词仍应按原条件执行。

项目能采用 2.1.0 时，按原依赖管理流程更新并锁定版本，再用原来会漏行的快照检查。2.0 到 2.1 可能还有其他变更，需覆盖实际读取字段、删除向量和分区配置；不能只验证一个时间字段就给整张表的所有特性作保证。

暂时不能升级时，可在明确容量和一致性约束后采用已经对照正确的读取路径，再应用原始过滤条件。不要直接扫描整个 Parquet 目录绕过 Delta 事务日志，那会引入活动文件与逻辑删除的另一类错误。

已完成的增量任务也要核对

保存最后可信水位线与受影响任务输出，按原时间精度重查对应快照的边界区间。若要重放，先按业务幂等或主键规则处理重复，不能简单把水位线往回移后重复写入所有数据。

验收覆盖毫秒正点、同一毫秒内部的微秒值、恰好等于水位线，以及包含时区的实际字段。比较主键集合与时间值，不能只看总行数；已有错误结果需要重算，升级依赖本身不会把漏掉的记录补进下游。