feat(consignment): 一个寄卖单号锚定全流程 + 统一状态机 + 卖家侧确认加好友/提交赠送截图

问题：一件货身上挂着三套互不相通的状态（提报单审核态、仓库库存态、工单赠送态），
my-items 同时返回两个数组、卖家端分两个列表渲染，同一件货显示两行两个号；
且卖家端只映射了前两套状态，"已出库"之后流程就断了，卖家不知道该干什么。

- 提报单号 SUB… 作为唯一「寄卖单号」从发布锚定到结算（零迁移）；
  listWorkerConsignments 改成一件货一条记录，库存/工单信息挂上去，
  客服手工入库的现货（无提报单）才回退用库存号当锚点
- 新增 domain/consignment-item-stage.ts：把三套底层状态推导成卖家看得懂的一个阶段
  （待审核/已通过待匹配/已匹配-待加好友/冷却中/待赠送/已赠送待审核/已完成/驳回/作废/取消）
  + 一句"下一步做什么" + 能力位（谁能确认加好友、谁该传截图），列表筛选与 KPI 也改由它驱动
- 卖家侧新增动作（以前只有 publish + my-items，卖家只能干看）：
  POST /worker/consignment/items/:submissionId/{confirm-friend,gift-evidence}
  POST /worker/consignment/inventories/:inventoryId/{confirm-friend,gift-evidence}（手工入库现货）
  复用既有工单链路 confirmWorkOrderFriendAdded / submitWorkerOrderAcceptance，
  只加归属校验（不是本人履约的订单 403），顺带白拿"冷却没结束不许提交凭证""必须带图"
- 客服端用同一个号：库存列表/详情补 sourceSubmissionNo（LEFT JOIN 提报单），
  履约/指派写进工单的寄售信息也带上；关键字搜索支持按寄卖单号搜（计数 SQL 同步补 join）

真实库端到端验证：确认加好友 → gift_phase=friend_countdown / friend_added_at 落库 /
gift_available_at 正好 +72h；冷却期内提交截图被拒（work_order_gift_cooldown_active）；
越权操作被拒（consignment_item_not_found）；按寄卖单号搜索命中正确。临时数据已清理。

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` |
+| 本批提交（批次 I，同一提交内含本文档，故不写自身 hash） | 批次 I：提报单号为唯一寄卖单号（一件货一行）+ 统一状态机 + 卖家确认加好友/提交赠送截图 | `consignment-item-stage.ts`、`consignment-worker-service.ts`、`routes/worker/consignment.ts`、`ConsignmentInventoryPanel.tsx`、`WorkerConsignmentPage.tsx` |
 | 本批提交（批次 H，同一提交内含本文档，故不写自身 hash） | 批次 H：修掉发布时乱弹内部库存提醒（部分匹配兜底过宽）+ 弹窗赏金分/元换算 | `consignment-matching-service.ts`、履约复检、`WorkOrdersPanel.tsx` |
 | 本批提交（批次 G，同一提交内含本文档，故不写自身 hash） | 批次 G：确认加好友后现货作废不回池 + 撤销寄售履约押金可选（含修打手押金永久冻结、真实库 42804 500） | `consignment-repo.ts`、`consignment-deposit-policy.ts`、`work-order-deposit-repo.ts`、撤销履约服务与路由、`WorkOrdersPanel.tsx` |
 | 本批提交（批次 F2，同一提交内含本文档，故不写自身 hash） | 批次 F2：确认加好友后卖家发布押金不退（`deposit_deduction` 落地）+ 二次冻结护栏 | `consignment-deposit-repo.ts`、取消/退单仓库、撤销履约服务 |
@@ -278,6 +279,45 @@
    前端在"部分匹配"候选上先 `modal.confirm` 危险确认，再带 `allowPartial: true` 重试，高配充低配的合法玩法保留但不可误触。
 3. ⏳ 匹配下推 SQL + 批量匹配接口 + 工单列表角标（P2-8）未做：当前仍是"取全量在库 → 内存比对"。
 
+### 批次 I · 一个单号锚定 + 统一状态机（本轮）
+
+**问题**：一件货在系统里有三层互不相通的状态——提报单（`SUB…`，审核态）、库存（`INV…`，仓库态）、
+工单赠送（`material_required / friend_countdown / pending_acceptance / accepted`）。
+`my-items` 同时返回两个数组、前端分两个列表渲染，于是**同一件货两行、两个号**；
+更糟的是卖家端只映射了前两套状态，"已出库"之后流程就断在黑暗里，
+卖家不知道已经匹配、不知道该加好友、不知道在冷却、不知道该赠送。
+
+**改法**：
+
+1. ✅ **提报单号 `SUB…` 作为唯一「寄卖单号」**，从发布锚定到结算（零迁移，历史数据直接可用）。
+   `listWorkerConsignments` 改成**一个提报单一条记录**：库存、绑定工单的信息挂上去，
+   客服手工入库的现货（没有提报单）才用库存号当锚点。真实库验证：打手 3 的 2 件货从 4 行收敛成 2 行。
+2. ✅ **统一状态机** `domain/consignment-item-stage.ts`（纯函数、可单测），把三套底层状态推导成
+   卖家看得懂的一个阶段 + 一句"下一步该做什么"：
+   待审核 → 已通过（在库待匹配）→ 已匹配-待加好友 → 加好友赠送冷却中 → 待赠送
+   → 已赠送待审核 → 已完成；另有 已驳回 / 已下架作废 / 已取消，以及标准验收单的 履约中 / 待验收。
+   列表筛选与 KPI 也改由它驱动（待审核 / 履约中 / 已完成）。
+3. ✅ **卖家可以在「我的寄卖」操作**（以前只有 publish + my-items 两个接口，卖家只能干看）：
+   - `POST /worker/consignment/items/:submissionId/confirm-friend`：确认已加好买家好友 →
+     进入赠送冷却期；前端弹窗明确写「确认后进入赠送冷却期、未完成赠送押金不退」。
+   - `POST /worker/consignment/items/:submissionId/gift-evidence`：上传赠送截图给客服审核。
+   - 客服手工入库的现货没有提报单，另开 `POST /worker/consignment/inventories/:inventoryId/...`
+     两个路由走同一套动作（**不做"一个 id 两义"**，避免提报单号与库存号撞号时误操作别人的货）。
+   - 两个动作都**复用既有工单链路**（`confirmWorkOrderFriendAdded` / `submitWorkerOrderAcceptance`），
+     只加一道归属校验：不是本人履约的订单直接 403，卖家碰不到别人的单。
+     顺带白拿了既有的强校验：**冷却没结束不许提交凭证**、必须带图。
+4. ✅ **客服端同号**：库存列表/详情接口补 `sourceSubmissionNo`（LEFT JOIN 提报单），
+   履约/指派写进工单的寄售信息也带上 `sourceSubmissionNo`，客服面板与工单详情显示同一个寄卖单号
+   （历史老单回退显示仓库号）。
+
+**真实库端到端验证**（提报单线与手工入库线各跑一遍）：卖家「确认加好友」→
+`gift_phase=friend_countdown`、`friend_added_at` 落库、`gift_available_at` 正好 +72 小时；
+冷却期内提交赠送截图被拒（`work_order_gift_cooldown_active`）；
+换另一个打手来操作被拒（`consignment_item_not_found`）。临时数据已清理。
+
+**遗留**：列表按 `pageSize: 200` 拉全量再聚合，单个卖家寄卖件数超过 200 时需改成游标分页；
+`pending_acceptance` 仍在寄卖可撤销白名单内（见 P2-7）；客服长时间不点「确认加好友」没有超时策略（按业务确认先不管）。
+
 ### 批次 H · 修掉"乱弹匹配提醒"与"赏金没换算成元"（本轮）
 
 1. ✅ **发布时不再乱弹「内部寄售库存匹配提醒」**：