## Why

修正业务方案审查后，确认 5 项业务逻辑补全仍未完成：佣金链断裂静默跳过、C端订单 Handler 绕过 Service 层直接查 DB、富友支付留桩未实现、平台无法代用代理钱包购包、卡/设备激活后状态字段未更新。这些问题直接影响业务正确性：佣金链断裂导致平台无法发现缺配置的代理、Handler 绕层违反架构约束、富友支付无法上线、平台运营受限、资产状态不反映真实使用情况。

## What Changes

- **F-1 佣金链断裂改为零额待审记录**：`commission_calculation/service.go` 中佣金链断裂（代理缺少套餐系列授权）时，不再静默 `break`，改为创建 `amount=0, status=99(待人工修正)` 的佣金记录并记录告警日志，让平台管理员能发现并处理。新增常量 `CommissionStatusPendingReview = 99`。
- **F-4 C端订单 Handler 迁移到 Service 层**：`internal/handler/app/client_order.go` 中直接 `h.db.WithContext(resolved.SkipPermissionCtx)` 查询数据库的代码，迁移到 `internal/service/client_order/service.go` 新增 `ListOrders` / `GetOrderDetail` 方法，Handler 改为调用 Service。
- **J-1 富友支付实现**：`order/service.go` 中 `FuiouPayJSAPI` 和 `FuiouPayMiniApp` 从留桩（返回"暂未实现"）改为真实调用 `pkg/fuiou/` SDK 完成预下单。回调链路已存在，无需修改。需在 DB 插入富友支付凭证配置。
- **J-2 平台钱包代购**：`order/service.go:CreateLegacy` 的钱包支付分支，新增支持平台操作人用某代理钱包给该代理名下资产购包的场景（`buyerType="" && resourceShopID != nil`）。
- **J-3 卡/设备 status 3/4 业务触发**：套餐激活成功后自动将 `iot_card.status` / `device.status` 更新为 3（已激活）；最后一个 active 套餐到期后更新为 4（已停用）。

## Capabilities

### New Capabilities

- `commission-pending-review`: 佣金链断裂时创建零额待审记录，支持按 status=99 筛选

### Modified Capabilities

- `client-order-purchase`: C端订单查询迁移到 Service 层，删除 Handler 直接 DB 访问
- `fuiou-payment`: 从留桩改为真实实现 JSAPI 和 MiniApp 预下单
- `admin-order-creation`: 平台钱包代购场景支持
- `asset-lifecycle-status`: 卡/设备 status 字段 3（已激活）和 4（已停用）的自动触发

## Impact

- **新增文件**：无（`commission-pending-review` 的逻辑内嵌到现有 `commission_calculation/service.go`）
- **修改文件**：`internal/service/commission_calculation/service.go`、`internal/handler/app/client_order.go`、`internal/service/client_order/service.go`、`internal/service/order/service.go`、`internal/service/package/activation_service.go`（或套餐激活相关文件）
- **新增常量**：`CommissionStatusPendingReview = 99`
- **DB 操作**：需插入富友支付凭证到 `tb_wechat_config`（J-1）
- **无 DB 迁移**（schema 不变）
- **前端影响**：佣金记录列表需支持 `status=99` 筛选（F-1）