docs(finance): record credit wallet rollout

开发环境独立任务协作登记.md

@@ -43,7 +43,7 @@
 
 本节点先跑通客户充值申请、平台审核、平台手工充值/扣款、余额与流水；微信/支付宝商户支付回调、订单消费、冻结/解冻及自动扣费后续另批处理。付款渠道仅展示已配置的静态收款二维码，客户提交金额、付款方式和付款截图后进入待审核。
 
-资金口径固定为 CNY：`可用余额 = 实际余额 - 冻结金额`。本批冻结金额持久化且初始为 0；充值审核通过或平台手工充值原子增加实际余额和可用余额，平台手工扣款原子减少实际余额和可用余额且不得超过可用余额。每次成功变动必须生成唯一业务单号和不可变流水；同一幂等键同载荷重试返回原结果，不同载荷冲突，重复审核不得重复入账。
+资金口径固定为 CNY：`可用授信 = 授信额度 - 已用授信 - 冻结授信`，`总可用余额 = 实际余额 + 授信额度 - 已用授信 - 冻结金额`。冻结金额包含实际资金冻结与授信冻结；扣款先使用未冻结实际资金，再使用授信，充值先归还已用授信，再增加实际余额。初始授信由 Finance 环境配置统一设置，平台可按客户调整。每次成功变动必须生成唯一业务单号和不可变流水；同一幂等键同载荷重试返回原结果，不同载荷冲突，重复审核不得重复入账。
 
 | 工作包 | 执行任务 | 写入范围 | 交付目标 | 依赖与集成边界 |
 |---|---|---|---|---|
@@ -61,6 +61,8 @@
 - 开发部署最终结果：Backend Jenkins `#171`（下游 Finance `#26`）、Admin `#45`、Client `#45` 均为 `SUCCESS`；Admin、Client 与国内 API 健康检查均返回 HTTP 200。开发环境以 `DEPLOY_ENV=development` 启用明确标注“开发示例、不可付款”的静态二维码，其他部署环境保持默认关闭。
 - 真实 HTTP 验收使用客户登录态提交 PNG 付款截图：创建返回 `PENDING`，相同幂等键重放返回原申请，不同载荷返回 `FIN-IDEMPOTENCY-CONFLICT`；凭证下载为 HTTP 200 `image/png`；审核后余额从 ¥15 增至 ¥115，重复审核返回 `FIN-WALLET-409`；另一申请驳回后余额不变。手工充值 ¥25、扣款 ¥10 成功并生成流水，超额扣款返回 `FIN-WALLET-INSUFFICIENT`；最终 `实际余额 ¥115 = 冻结金额 ¥0 + 可用余额 ¥115`。
 - 已按 `1920×1080`、浏览器缩放 `100%` 验收 Client 资金账户、流水、充值记录与充值弹窗，以及 Admin 客户筛选、账户详情、充值记录、凭证和手工充值/扣款表单。Client 资金页的账户、流水、申请、渠道接口各请求 1 次；Admin 去重修复后详情流水与充值申请接口各请求 1 次，未发现遮挡或横向溢出。
+- 授信与冻结结算扩展已完成：Backend 提交 `ba4407eb`、权限断言修复 `ede63fac`，Admin 提交 `92b24cc`，Client 提交 `46a91fb`，财务契约提交 `08a80e7`。Finance 提供服务令牌保护的账户查询、冻结、结算和释放内部接口；初始化授信配置为 `FINANCE_WALLET_DEFAULT_CREDIT_LIMIT`，默认 `0.00`。
+- 最新开发部署为 Backend Jenkins `#173`（下游 Finance `#29`）、Admin `#46`、Client `#46`，均为 `SUCCESS`。国内统一增量从首行完整执行并取得 `migration_status=PASS`；真实 HTTP 授信回归 `13/13` 通过，验证授信调整、现金优先扣款、额度下限门禁、充值优先归还授信及最终余额恢复。验收后账户为实际余额 `¥115.00`、冻结金额 `¥0.00`、授信额度/已用授信/冻结授信均为 `¥0.00`、总可用余额 `¥115.00`。
 
 ## 当前 P0 全流程补齐批次