refactor: 流量系统重构 — 增量累加算法 + 日粒度缓冲 + 旧详单清理

核心改造：
- 增量算法：流量计算从覆盖式改为增量累加（gateway - lastReading），支持上游运营商重置检测
- 日流量缓冲：insertDataUsageRecord 改为 Redis INCRBYFLOAT，每日凌晨落盘到 tb_card_daily_usage
- 运营商：新增 data_reset_day 字段（联通=27，其余=1）
- IoT卡：新增 last_gateway_reading_mb 字段存储上次网关读数
- 查询层：新建 TrafficQueryService 合并 Redis（今日）+ DB（历史）数据源
- 清理：删除 DataUsageRecord model/store，移除 polling_handler 旧引用

迁移：000094-000097（carrier字段、iot_card字段、数据初始化、日流量表）

openspec/specs/client-order-purchase/spec.md

@@ -44,3 +44,20 @@
 #### Scenario: 异步任务连续失败
 - **WHEN** AutoPurchaseAfterRecharge 连续执行失败且达到最大重试次数
 - **THEN** 系统将充值记录 `auto_purchase_status` 更新为 `failed`
+
+---
+
+## MODIFIED Requirements
+
+### Requirement: C端支付状态枚举统一
+C端订单查询接口返回的 `payment_status` SHALL 直接使用管理端统一枚举值（1=待支付, 2=已支付, 3=已取消, 4=已退款），不再通过映射函数转换为 0/1/2。
+
+#### Scenario: C端查询订单返回统一枚举
+- **WHEN** C端客户查询订单列表或订单详情
+- **THEN** 返回的 `payment_status` SHALL 为 1/2/3/4 之一，与管理端一致
+
+## REMOVED Requirements
+
+### Requirement: C端支付状态映射
+**Reason**: `orderStatusToClientStatus()` 函数将管理端 1/2/3/4 映射为 C端 0/1/2，造成前后端枚举不一致，增加维护负担。
+**Migration**: C端前端需更新支付状态枚举解析：1=待支付, 2=已支付, 3=已取消, 4=已退款。