fix(consignment): 验收结算补上寄卖货款，并修指派打手线报酬 100 倍单位错

问题：工单 #100171 验收完成时卖家钱包只有押金 -20/+20，货卖掉了但货款收益没进卖家钱包。

查证：工单报酬 reward_amount=14500 分（发单方付 ¥145），货的结算价 cost_price_fen=12400 分
（卖家应得 ¥124），而 assigned_worker_id 为空（内部现货履约）。通用结算的规则是"把工单报酬
付给接单人"，内部现货单没有接单人 → 这笔钱谁也没拿到，卖家只拿回自己的押金。

- 新增 settleConsignmentSupplierPayoutByWorkOrderWithClient()：验收完成时把货的结算价
  （cost_price_fen，缺省退回 asking_price_fen）补给供货卖家，单位与通用报酬一致（分），
  同样做售后欠款抵扣、按售后策略决定是否延迟解冻、写 reward_settlement/reward_pending_unfreeze
  流水（说明「寄卖货款结算 #单号」）
- 不重复付款：接单人就是供货卖家本人时跳过（指派打手线里货物已随工单报酬付过）
- 修 100 倍单位错：指派打手线把工单报酬改写成货的结算价时写了 (cost_price_fen/100).toFixed(2)，
  ¥124 被写成 ¥1.24；reward_amount 的单位是分（已用真实数据核对）。抽成纯函数
  resolveConsignmentAssignRewardFen() 并加测试钉住单位

真实库端到端验证：卖家钱包 ¥205.50 → ¥329.50（+¥124.00 寄卖货款结算），累计结算同步 +¥124.00；
验证脚本改动的开发库数据已还原，临时数据残留 0。

docs/寄卖系统优化方案.md

@@ -21,6 +21,7 @@
 | `632dddc4` | 上一轮：H5 渠道整体下线 + 凭据字段修复 + 状态机封闭（撤销守卫 / 库存绑定唯一性 / 生命周期解绑）+ 押金归属取台账 | 迁移 `079`、`consignment-*` 五个文件、`work-order-*` 三个仓库、两个前端面板 |
 | `5d11bf20` | 批次 C+D：指派部分成功补偿、凭证核销如实反馈、空规格不放行 + 履约/指派服务端规格复检 | `consignment-fulfillment-service.ts`、`consignment-matching-service.ts`、`consignment-repo.ts`、履约路由、`WorkOrdersPanel.tsx` |
 | `d6f6219f` | 批次 F1：内部现货履约停在「待加好友」，客服确认后才进赠送冷却 + 备注快捷项 | `work-order-gift-repo.ts`、履约服务、`WorkOrdersPanel.tsx`、`utils/gift-phase.ts` |
+| 本批提交（批次 Q，同一提交内含本文档，故不写自身 hash） | 批次 Q：验收结算补寄卖货款给供货卖家；修指派打手线报酬 100 倍单位错 | `consignment-deposit-repo.ts`、`work-order-settlement-repo.ts`、`consignment-fulfillment-service.ts` |
 | 本批提交（批次 P，同一提交内含本文档，故不写自身 hash） | 批次 P：确认加好友/上传赠送截图恢复为卖家操作，客服兜底 | `consignment-item-stage.ts`、`consignment-worker-service.ts`、`worker-acceptance-service.ts` |
 | 本批提交（批次 O，同一提交内含本文档，故不写自身 hash） | 批次 O：文件链接去掉签名与有效期（修客服端凭证裂图），寄卖出参统一归一化 | `file-storage-service.ts`、`routes/files.ts`、`consignment-admin-service.ts` |
 | 本批提交（批次 N，同一提交内含本文档，故不写自身 hash） | 批次 N：删掉按库存号的卖家入口，卖家动作只按寄卖单号定位 | `consignment-worker-service.ts`、`routes/worker/consignment.ts`、`WorkerConsignmentPage.tsx` |
@@ -286,6 +287,50 @@
    前端在"部分匹配"候选上先 `modal.confirm` 危险确认，再带 `allowPartial: true` 重试，高配充低配的合法玩法保留但不可误触。
 3. ⏳ 匹配下推 SQL + 批量匹配接口 + 工单列表角标（P2-8）未做：当前仍是"取全量在库 → 内存比对"。
 
+### 批次 Q · 补上寄卖**货款**结算（本轮）
+
+**问题（用户对账发现）**：工单 #100171 验收完成时，卖家钱包只有两笔——发布押金 -20 又 +20。
+**货卖出去了，但货款的收益没进卖家钱包。**
+
+**查证**：
+
+| 项 | 值 |
+| --- | --- |
+| 工单报酬 `reward_amount` | 14500 分（¥145.00，发单方付给平台） |
+| 货的结算价 `cost_price_fen` | 12400 分（¥124.00，卖家应得） |
+| 接单人 `assigned_worker_id` | 空（内部现货履约，客服/内部仓代交付） |
+
+通用验收结算的规则是"把工单报酬付给**接单人**"。内部现货履约的单子**没有接单人**，
+于是这笔钱谁也没拿到；而卖家交付了自己的货，只拿回了自己的押金。差价（¥21）本该是平台的。
+
+**改法**：
+
+1. ✅ 新增 `settleConsignmentSupplierPayoutByWorkOrderWithClient()`：验收完成时，
+   把货的结算价（`cost_price_fen`，缺省退回提报的 `asking_price_fen`）补给**供货卖家**，
+   金额单位与通用报酬一致（分），并同样做售后欠款抵扣、按售后策略决定是否延迟解冻、
+   写 `reward_settlement` / `reward_pending_unfreeze` 流水（说明「寄卖货款结算 #单号」）。
+2. ✅ **不重复付款**：接单人就是供货卖家本人时跳过——指派打手线里接单人正是卖家本人，
+   货款已经随工单报酬付过了（见下一条），只有"没人收"的那一份才在这里补。
+3. ✅ **顺带修掉一个 100 倍单位错**：指派打手线把工单报酬改写成"货的结算价"时，
+   写的是 `Number((cost_price_fen / 100).toFixed(2))` → **¥124 被写成 ¥1.24**，
+   卖家只能拿到结算价的百分之一。`reward_amount` 的单位是**分**（与钱包、流水一致，
+   已用真实数据核对：`reward_amount=2500` 对应流水 `2500`、界面 ¥25.00）。
+   现在抽成纯函数 `resolveConsignmentAssignRewardFen()` 并加测试钉住单位。
+
+**真实库端到端验证**（内部现货履约，结算价 ¥124 / 发单方付 ¥145）：
+
+| 步骤 | 结果 |
+| --- | --- |
+| 验收前卖家钱包 | 可用 ¥205.50，累计结算 ¥297.50 |
+| 走真实验收结算 | 订单转 `accepted` |
+| 本次流水 | `reward_settlement ¥124.00 寄卖货款结算 #100175` |
+| 验收后卖家钱包 | 可用 **¥329.50**（+¥124.00），累计结算 ¥421.50（+¥124.00）✅ 等于货的结算价 |
+
+验证脚本改动的开发库数据已还原（钱包恢复 ¥205.50 / 累计结算 ¥297.50，等级未被触发变更），临时数据残留 0。
+
+**遗留**：用户对账时看到的 #100171 是在本批修复**之前**结算的，所以它当时确实没发货款（¥124.00）。
+要不要给这类历史单补一笔，等用户确认。
+
 ### 批次 P · 「确认加好友 / 上传赠送截图」恢复为卖家操作（本轮）
 
 **问题（用户截图：卖家端的货点不了确认加好友）**：卖家「我的寄卖」里那件"已匹配-待加好友"的货，