feat: add recharge callback processing

docs/04-architecture.md

@@ -42,6 +42,8 @@ T-302 已实现 `/api/v1/generate/title` 与 `/api/v1/generate/image`：API 层
 
 T-303 已实现 `/api/v1/balance`：外部 API 继续只认 API Key，API 层调用 `apps.billing.services.get_balance_snapshot()` 读取当前钱包余额；测试覆盖余额响应与流水累加一致的场景。
 
+T-304 已实现 `/api/v1/recharge/callback/wechat` 与 `/api/v1/recharge/callback/alipay`：两个回调端点均 `@csrf_exempt` 且不挂登录态；回调验签后调用 `apps.billing.services.apply_recharge_payment()`，按 `order_no` 锁定 `RechargeOrder` 幂等入账，金额或通道不一致不加点。缺真实商户配置时仅允许使用明确的 HMAC mock 模式联调，生产应切换 `PAYMENT_CALLBACK_MODE=sdk`。
+
 **计费层（`apps/billing`）**
 
 - 计费规则查询：按「操作类型 + 能力别名（+ 可选分辨率）」算出本次点数 N。**按别名定价，不按具体供应商 SKU 定价**，这样后台换底层模型时计费不变。
@@ -230,7 +232,7 @@ CREATE TABLE points_ledger (
   change_type   TEXT NOT NULL,    -- recharge / consume / adjust / refund
   points_delta  BIGINT NOT NULL,  -- 正为加、负为减
   balance_after BIGINT NOT NULL,  -- 变动后余额，便于对账
-  ref_order_id  INTEGER,          -- T-201 先存数值引用；RechargeOrder 落地后再正式关联
+  ref_order_id  INTEGER,          -- 数值引用 RechargeOrder.id；T-304 已加 ref_order_id+change_type 唯一兜底
   ref_call_id   INTEGER REFERENCES call_record(id),
   reason        TEXT,             -- 运营手工调整必填原因
   created_at    TEXT NOT NULL
@@ -266,7 +268,7 @@ CREATE TABLE call_record (
 - `payment_user_id`、`payment_txn_no` 为对账预留，字段先建。
 - `recharge_order.exchange_rate` 与 `points_granted` 在下单时写入，状态为 `pending` 时也必须有值；支付回调金额必须与订单金额一致，入账时不得按新的汇率重算。
 - `call_record.status` 状态机为 `pending -> success / failed`。上游失败退点后仍保持 `failed`，退款流水通过 `points_ledger(change_type=refund, ref_call_id=call_record.id)` 关联，不单独增加 `refunded` 状态，避免调用结果与账务动作混在一个字段里。
-- T-201 已落地 `UserWallet` / `ApiKey` 于 `apps.users`，`PointsLedger` / `CallRecord` 于 `apps.billing`；T-203 已落地扣点/退点服务；`ref_order_id` 在充值订单模型落地前保持索引化数值引用。
+- T-201 已落地 `UserWallet` / `ApiKey` 于 `apps.users`，`PointsLedger` / `CallRecord` 于 `apps.billing`；T-203 已落地扣点/退点服务；T-304 已落地 `RechargeOrder`、回调幂等入账服务和 `points_ledger(ref_order_id, change_type)` 复合唯一约束，`ref_order_id` 当前仍为数值引用 `RechargeOrder.id`。
 
 ## 四、计费时序（核心，务必照此实现）