fix: 资产钱包自动创建机制 — 修复C端购买时钱包不存在报错

- client_order: 新增 getOrCreateWallet 兜底，钱包不存在时自动创建
- device_import: 设备导入事务内同步创建设备钱包
- iot_card_import: IoT卡批量导入后批量创建卡钱包
- queue/handler: 传递 AssetWalletStore 给两个导入 handler
- migration 000098: 为存量IoT卡和设备补建资产钱包

openspec/changes/archive/2026-03-28-fix-code-quality-cleanup/specs/admin-order-creation/spec.md

@@ -0,0 +1,12 @@
+## MODIFIED Requirements
+
+### Requirement: 后台订单钱包支付权限校验
+后台创建订单时，若支付方式为钱包支付，Handler 层 SHALL 校验当前操作人为代理账号（`user_type = agent`）。非代理账号使用钱包支付 SHALL 在 Handler 层即被拦截，返回参数错误。
+
+#### Scenario: 非代理账号使用钱包支付被拦截
+- **WHEN** 平台用户或企业用户提交订单且 `payment_method = wallet`
+- **THEN** Handler SHALL 返回 `CodeInvalidParam` 错误，提示"仅代理账号可使用钱包支付"，请求不会到达 Service 层
+
+#### Scenario: 代理账号使用钱包支付正常通过
+- **WHEN** 代理账号提交订单且 `payment_method = wallet`
+- **THEN** Handler SHALL 放行，由 Service 层继续处理钱包扣款逻辑

openspec/changes/archive/2026-03-28-fix-code-quality-cleanup/specs/asset-queries/spec.md

@@ -0,0 +1,8 @@
+## MODIFIED Requirements
+
+### Requirement: 资产查询错误处理
+资产查询 Service 在获取绑定卡信息时，数据库查询错误 SHALL 被记录到日志而非被静默忽略。查询失败 SHALL NOT 中断主查询流程，但 SHALL 记录 Warn 级别日志，包含失败的卡 ID 列表和错误详情。
+
+#### Scenario: 绑定卡查询失败时记录日志
+- **WHEN** `iotCardStore.GetByIDs()` 返回错误
+- **THEN** 系统 SHALL 记录 Warn 日志（含 card_ids 和 error），继续返回已有数据，不返回错误给调用方

openspec/changes/archive/2026-03-28-fix-code-quality-cleanup/specs/asset-suspend-resume/spec.md

@@ -0,0 +1,12 @@
+## MODIFIED Requirements
+
+### Requirement: 停复机回调注入
+系统启动时 SHALL 在 bootstrap 阶段注入停复机回调，确保停机/复机操作完成后自动触发套餐联动逻辑（暂停/恢复套餐计时）。
+
+#### Scenario: 系统启动后回调已注入
+- **WHEN** API 或 Worker 服务完成 bootstrap 初始化
+- **THEN** `usageService.SetStopResumeCallback(stopResumeService)` 和 `activationService.SetResumeCallback(stopResumeService)` SHALL 已被调用
+
+#### Scenario: 停机触发套餐暂停
+- **WHEN** 管理员对卡执行停机操作且回调已注入
+- **THEN** 停机成功后 SHALL 自动触发套餐暂停联动逻辑

openspec/changes/archive/2026-03-28-fix-code-quality-cleanup/specs/client-order-purchase/spec.md

@@ -0,0 +1,14 @@
+## 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=已退款。