fix(consignment): 复核修复——占库撞 080 CHECK 必 500、指派非卖家双付货款、手动匹配权限门控

- 占库默认 allocation_status 从自由文本改为「已安排」，不再撞 080 的
  CHECK ('待安排','已安排')；加静态守卫测试（剥注释断言枚举内默认值）
- resolveConsignmentAssignRewardFen 加 assigneeIsSupplier：指派供货卖家本人
  → 报酬=结算价（货款走报酬渠道）；指派别的打手 → 报酬保持原值（货款走
  供货货款渠道），两条渠道互斥，封住平台双付；补行为级测试 + 调用点钉住
- 手动匹配两处入口（库存面板行内按钮、拦截弹窗 footer）统一按
  consignment.fulfill 门控，编辑/作废仍为 manage，与后端权限一一对应
- docs/寄卖系统优化方案.md 记录批次 U

后端 473（+3）/ 前端 49（+1）测试全绿，typecheck / lint / format / check:sql / build 通过

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` |
+| 本批提交（批次 U，同一提交内含本文档，故不写自身 hash） | 批次 U：复核修复——占库 allocation_status 撞 080 CHECK（真实库必 500）、指派非供货卖家时货款双付、手动匹配入口按 fulfill 权限门控 | `consignment-repo.ts`、`consignment-fulfillment-service.ts`、两个面板、三个测试文件 |
 | 本批提交（批次 S，同一提交内含本文档，故不写自身 hash） | 批次 S：手动指定现货匹配（判定/差异/强制留痕 + 双向入口 + 共享弹窗） | `consignment-matching-service.ts`、`consignment-fulfillment-service.ts`、`ConsignmentManualMatchModal.tsx` |
 | 本批提交（批次 R，同一提交内含本文档，故不写自身 hash） | 批次 R：售后立案回落到供货卖家；抽共享"从工单找供货卖家"查询 | `consignment-supplier-repo.ts`、`after-sales-repo.ts`、`consignment-deposit-repo.ts` |
 | 本批提交（批次 Q，同一提交内含本文档，故不写自身 hash） | 批次 Q：验收结算补寄卖货款给供货卖家；修指派打手线报酬 100 倍单位错 | `consignment-deposit-repo.ts`、`work-order-settlement-repo.ts`、`consignment-fulfillment-service.ts` |
@@ -288,6 +289,34 @@
    规格冲突 → 409 `consignment_spec_mismatch`；非 exact 且未显式传 `allowPartial` → 409 `consignment_spec_partial_requires_confirm`。
    前端在"部分匹配"候选上先 `modal.confirm` 危险确认，再带 `allowPartial: true` 重试，高配充低配的合法玩法保留但不可误触。
 3. ⏳ 匹配下推 SQL + 批量匹配接口 + 工单列表角标（P2-8）未做：当前仍是"取全量在库 → 内存比对"。
+### 批次 U · 复核修复：占库 500 / 指派双付 / 手动匹配权限门控（本轮）
+
+对 `94328ac6..0476339e` 做了一轮对抗复核（两个并行审查 + 人工验证），修三处：
+
+1. ✅ **P0 指派打手占库在真实库必 500**：`claimConsignmentInventoryForWorker` 的
+   `allocation_status` 默认值是自由文本「已指派打手(押金履约中)」，撞上迁移 `080` 的
+   `CHECK ('待安排','已安排')`。假 client 单测不跑真 SQL 一直没暴露（与当年 42804 同病）。
+   默认值改为「已安排」，并加静态守卫测试（剥掉注释后断言默认值必须在枚举内，
+   防止注释里引用历史值误伤）。
+2. ✅ **P1 指派非供货卖家时货款双付**：`resolveConsignmentAssignRewardFen` 以前无条件把
+   工单报酬改写成结算价。指派了别的打手时（API 层允许，界面不会主动构造）：打手按结算价
+   拿一份 + 卖家再拿一份供货货款（`settleConsignmentSupplierPayout` 只在"接单人===卖家"时
+   跳过）= 平台双付。现在纯函数加 `assigneeIsSupplier` 参数：卖家本人履约 → 报酬=结算价
+   （货款走工单报酬渠道）；别的打手 → 报酬保持原值（货款走供货货款渠道），两条渠道互斥。
+   补行为级测试 + 调用点静态钉住（判定基准必须是 `inventory.worker_id`）。
+3. ✅ **P1 手动匹配入口权限错位**：库存面板「手动匹配订单」挂在 `consignment.manage` 门下、
+   拦截弹窗 footer「手动指定现货匹配」没门控，而两个动作提交打到要求 `consignment.fulfill`
+   的 `/fulfill`、`/assign-worker` —— 只有 manage 的运营能点进去、选完单、点确认后必 403。
+   两处入口统一按 `canFulfillConsignment` 门控（编辑/作废仍为 manage，与后端权限一一对应），
+   mount 测试静态钉住。
+
+**验证**：后端 473 测试（+3）全绿、前端 49（+1）全绿；两侧 `typecheck` / `lint:check` /
+`format:check` / `check:sql` / `build` 通过。
+
+**复核中确认无需改动**：手动指定现货的服务端复检与留痕、售后回落卖家、卖家操作归属校验、
+删除类提交的残留引用 —— 均已核对无发现。遗留待办（拼单份额验收补寄卖钩子、文件接口登录态、
+弹窗 409 后刷新）见复核报告，未在本批处理。
+
 
 ### 批次 T · 手动匹配的入口修复（本轮）