## Context

API 与 Worker 分别创建订单服务。Worker 已为订单服务注入停复机模块，API 未注入；因此支付回调调用支付后自动复机入口时没有可执行的回调。支付后自动复机入口在事务提交后查询本订单的已生效主套餐，再异步调用停复机模块。

## Goals / Non-Goals

**Goals:**

- 使 API 支付回调复用既有的支付后自动复机入口。
- 保持“仅已生效主套餐触发”的现有查询语义和停复机资格判断。

**Non-Goals:**

- 不改变套餐权益状态、支付事务范围、Gateway 重试和轮询调度。
- 不让支付回调等待 Gateway 复机结果。
- 不新增队列、端口、数据表或配置。

## Decisions

### 在 API Composition Root 注入既有回调

在 API 创建订单服务后调用既有的 `SetResumeCallback(stopResumeService)`。这是 Worker 已使用的装配方式；复用同一模块可将卡/设备载体解析、有效套餐、剩余流量、实名、停机原因、分布式锁和 Gateway 调用保持在一个实现内。

不在支付回调中直接调用 Gateway，也不复制资格判断。直接调用会绕过已存在的幂等锁、设备多卡处理和审计/观测写入。

### 以事务提交后的已生效权益为复机前置条件

保留订单服务当前的查询：仅本订单 `status=Active` 且 `master_usage_id IS NULL` 的主套餐权益可触发复机。查询发生在支付与权益事务成功返回后，避免使用未提交或排队权益快照。复机模块在异步执行时重新读取卡及权益事实，防止并发状态变化导致错误复机。

## Risks / Trade-offs

- Gateway 调用仍是异步副作用；支付成功不等于复机成功。该取舍保持支付事实可靠落库，不将外部网络延迟或失败耦合到支付回调。
- API 进程现在可发起复机；其依赖已由同一 Composition Root 配置，且执行路径与 Worker 一致。