refactor(time): 时间列统一走 UTCDateTime，并把 MySQL 会话时区对齐成 UTC

问题不是「UTC 还是本地时间」，而是这套口径有两个半吊子的地方：

1. 库里存 naive UTC、读出来也是裸时间，于是每一处比较/输出都得自己补时区。
   项目里因此散了三份 _as_utc 和一堆 replace(tzinfo=UTC)，P1a 排下一轮时间
   时还炸过一次 TypeError: can't compare offset-naive and offset-aware。
2. MySQL 会话时区跟随系统 +08:00，而库里存的是 UTC —— SQL 里的 NOW()/
   CURDATE() 比库里的时间快 8 小时，查询会静默返回空（P1a 排查时就遇到过，
   看着像「没有数据」）。

改动：

- 新增 database.UTCDateTime：写时 aware→转 UTC 去 tzinfo、naive 视为 UTC；
  读时一律补 UTC 时区。底层 DDL 仍是 DATETIME，**不需要迁移**。models.py 的
  28 个时间列全部改用它，模型上的时间字段从此不再是裸值；
- docker-compose 给 mysql 加 --default-time-zone=+00:00，让 SQL 时间函数与存储
  口径一致。安全性已核实：全库 0 个 TIMESTAMP 列、0 个 CURRENT_TIMESTAMP
  默认值，改这里不会改变任何已有数据的语义；
- 新增 tests/test_utc_datetime.py：读出必须 aware、能直接和 datetime.now(UTC)
  比较、带 +08:00 的写入要落成 UTC、naive 写入视为 UTC，并有一条元测试扫描
  Base.metadata，防止以后新增时间列忘了用 UTCDateTime。

保留既有的 _as_utc 补丁（对 aware 值是幂等的，属防御性代码）；新代码不再需要。
「存 UTC、算 UTC、显示本地」三条线至此各自明确：存储与比较统一 UTC，日志按
容器 TZ 显示本地时间，前端 formatTime 负责转本地。

docker-compose.yml

@@ -122,6 +122,12 @@ services:
     command:
       - --character-set-server=utf8mb4
       - --collation-server=utf8mb4_0900_ai_ci
+      # 会话时区与存储口径对齐：库里所有时间列存的都是 UTC（应用一律写
+      # datetime.now(UTC)，MySQL 绑定参数丢掉 tzinfo 后落库即 UTC 裸值）。
+      # 若仍跟随系统 +08:00，SQL 里的 NOW()/CURDATE() 会比库里时间快 8 小时，
+      # 查询静默返回空、看着像「没数据」。全库无 TIMESTAMP 列、也没有
+      # CURRENT_TIMESTAMP 默认值，因此改这里不会改变任何已有数据的语义。
+      - --default-time-zone=+00:00
       # 业务表已超过 300MiB；可通过 .env 调整，默认给 MySQL 512MiB 缓冲池。
       - --innodb-buffer-pool-size=${MYSQL_INNODB_BUFFER_POOL_SIZE:-512M}
       # 默认记录 1 秒以上查询，便于验证查询优化；稳定后可设 MYSQL_SLOW_QUERY_LOG=0。