请先分析 report.py 和 test_report.py，暂时不要修改实现。
场景：后台按用户指定的本地日期统计订单。
数据：created_at 为 UTC Unix 秒；只统计 status=paid；金额为整数分。
保持 daily_report(db, day_text, zone='Asia/Shanghai') 的参数和返回键不变。
请指出日期、时区、SQL 区间的契约，列出可核对的 UTC 边界。
先运行测试并记录失败，不要把期望值改成旧代码的输出。

现在只修复 report.py，保持现有测试不变。
以 IANA 时区分别确定当天与次日的本地午夜，再转换成 UTC。
SQL 使用左闭右开区间，不能固定加 86400 秒。
遇到无效日期、未知时区、缺失或重复的午夜，明确拒绝，不猜测。
不增加网络调用，不连接线上库，不改金额和 paid 状态的业务规则。
完成后运行 python3 -m unittest -v test_report，说明实际结果与限制。

从评审角度检查修复，先不要改实现或已有测试。
独立检查：纽约秋季重复出现的两次 01:30 是否都能计入；
历史时区中有歧义的午夜是否按约定拒绝。
把新增用例写入 test_review.py，运行两组测试。
检查 diff，确认没有改返回结构、统计状态或金额单位。