fix(consignment): 匹配弹窗改用寄卖单号，客服界面不再展示内部仓库号

问题：内部寄售库存匹配弹窗显示的是「寄卖单号 INV26091711253394」——候选现货走的
是另一个查询 listActiveConsignmentInventoriesForMatching，它没 join 提报单，
sourceSubmissionNo 取不到，前端就回退显示内部仓库号；客服拿这个号去寄卖仓库又搜不到。

- 匹配候选查询补 LEFT JOIN consignment_submissions 带出 source_submission_no；
  该查询原本是 SELECT * 且列名无前缀，而 consignment_submissions 同样有
  status/game_name/category_id，加 join 会让条件变成 ambiguous column 直接 500，
  故列名统一加 ci. 前缀并显式列字段（加静态守卫测试钉住）
- 客服界面只展示寄卖单号：匹配弹窗候选卡片、工单寄售标识、工单详情、寄卖仓库列表与详情
  全部去掉内部仓库号；手工入库现货写「客服手工入库（无提报单号）」，
  历史老单写「老单无提报单号」，不再抛内部编号
- 内部仓库号保留：数据/接口/按它搜索都还在，撤销解绑等链路未动

真实库验证：仓库层候选查询与 checkWorkOrderInventoryMatches 都带出了寄卖单号。临时数据已清理。

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` |
+| 本批提交（批次 K，同一提交内含本文档，故不写自身 hash） | 批次 K：匹配弹窗改用寄卖单号（候选查询补 join），客服界面不再展示内部仓库号 | `consignment-repo.ts`、`WorkOrdersPanel.tsx`、`ConsignmentInventoryPanel.tsx` |
 | 本批提交（批次 J，同一提交内含本文档，故不写自身 hash） | 批次 J：凭证链可视化（提报凭证 + 赠送凭证），客服审核/仓库面板统一展示 | `consignment-admin-service.ts`、`consignment-repo.ts`、`ConsignmentSubmissionsPanel.tsx`、`ConsignmentInventoryPanel.tsx` |
 | 本批提交（批次 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` |
@@ -280,6 +281,28 @@
    前端在"部分匹配"候选上先 `modal.confirm` 危险确认，再带 `allowPartial: true` 重试，高配充低配的合法玩法保留但不可误触。
 3. ⏳ 匹配下推 SQL + 批量匹配接口 + 工单列表角标（P2-8）未做：当前仍是"取全量在库 → 内存比对"。
 
+### 批次 K · 匹配弹窗也改用寄卖单号，内部仓库号只留内部（本轮）
+
+**问题**：内部寄售库存匹配弹窗（发单时拦一下"有现货可直接履约"那个）显示的是
+`寄卖单号 INV26091711253394`——因为候选现货走的是**另一个查询** `listActiveConsignmentInventoriesForMatching`，
+它没 join 提报单，`sourceSubmissionNo` 取不到，前端就回退显示内部仓库号。
+结果是客服在弹窗里看到 INV，拿去寄卖仓库搜索又搜不到，还得自己换算。
+
+**改法**：
+
+1. ✅ 匹配候选查询补 `LEFT JOIN consignment_submissions` 带出 `source_submission_no`。
+   注意这个查询原来是 `SELECT *` + 不带前缀的列名，而 `consignment_submissions` 同样有
+   `status / game_name / category_id`——加 join 会让这些条件变成 ambiguous column 直接 500，
+   所以列名一律加 `ci.` 前缀并显式列出字段（已加静态守卫测试钉住这一点）。
+2. ✅ 客服界面**只展示寄卖单号**：匹配弹窗候选卡片、工单上的寄售标识、工单详情、寄卖仓库列表/详情
+   全部去掉内部仓库号；客服手工入库的现货明确写「客服手工入库（无提报单号）」，
+   历史老单写「老单无提报单号」，都不再抛内部编号。
+3. ✅ 内部仓库号 **保留**：仍在数据里、仍在接口里、**按它搜索依然搜得到**（后端两个关键字条件都覆盖），
+   撤销/解绑等链路一行没动。
+
+**真实库验证**：仓库层候选查询与匹配接口（`checkWorkOrderInventoryMatches`）在构造数据上都带出了
+寄卖单号（`VERIFY-MATCH-INV → VERIFY-MATCH-SUB`）。临时数据已清理。
+
 ### 批次 J · 凭证链可视化：提报凭证 + 赠送凭证（本轮）
 
 **问题**：一件寄卖有两类凭证，但客服界面只看得见第一类，而且是 48×48 一张缩略图，看不出是物品还是主页：