fix: 兼容相同顺运宝明细逐件回写 (#289)

docs/admin/03-data-model.md

@@ -1065,6 +1065,10 @@ CREATE UNIQUE INDEX idx_client_assignment_current
   不再接收聚合字符串：原商品明细承载一个码，额外单件使用数量 1、价格 0 的占位明细。
   JSON 数组按单件码保存 `detail_id/source/title/status` 检查点；新增或写入结果未知时立即
   转为 `needs_check`，重启后只读扫描整张货运单，不自动重发请求。
+- #289 复用同一个 JSON 字段保存另一种远端形态：当聚合记录的多个单件码恰好对应多条
+  已存在、数量均为 1 且规格和 SKU 身份完全相同的空白商品明细时，`source` 记为
+  `existing_matched`，按单件码顺序保存每个现成 `detail_id`。该规划在 `ready` 阶段已经
+  持久化，排队和回写前必须复读全部绑定明细；它不创建占位明细，也不改变数据库结构。
 - v28 增加可空 `source_sku_raw VARCHAR(500)`。数据库保留 Excel 单元格原文；匹配时仅
   去除两端空白后，与规格候选的 `sku` 或 `variationSku` 完全相等比较。唯一命中时它是
   高优先级确定性证据；重复命中或与档口货号唯一证据冲突时停止自动选择。缺失或零命中

docs/admin/08-顺运宝接口.md

@@ -410,7 +410,7 @@ SKU（平均每商品 1.17 个），**查无此 SKU 是常态**，不是异常
 `[建议]` 登录后**只调 `/am/user/get` 验证会话**，其余几个是网页自己的初始化请求，
 Go 侧不用跟着调。
 
-### 7.1 档口入库码逐件写入（工单 #234、#250、#278）
+### 7.1 档口入库码逐件写入（工单 #234、#250、#278、#289）
 
 档口入库码最终写入货运明细的 `innerExpCode`（页面名称“快递单号”）。接口来自
 现有 Python 流程和 HAR 响应样本：
@@ -433,6 +433,11 @@ POST /am/stock/detail/updateDetailCode?t=0&id={stockID}&detailId={detailID}&code
 - 回写前必须同时核对目标码数量、Excel 合并源行数和原商品 `productQty`；任一不一致时
   零写入。一个远端明细只写一个单件码，原明细为空时承载第一个缺失码，其余缺失码创建
   零价占位明细。
+- 顺运宝也可能已经用多条数量 1 的相同商品明细表达同一聚合记录。只有原始 SKU 重复
+  候选数、候选总件数、Excel 源行数和单件码数完全一致，并且全部候选的规格、`sku`、
+  `variationSku`、档口身份和采购状态一致时，才按稳定 `detailId` 与 Excel 单件码顺序形成
+  `existing_matched` 逐件规划。回写复用这些现成明细，不再创建占位明细；任一绑定在写前
+  变化时整条记录零写入并要求重新匹配。其他重复候选仍按真实歧义阻断。
 - 同一货运单任意明细已有目标码时直接复用，不删除、不搬移。稳定占位标题可用于识别
   “已创建但检查点未保存”的明细，防止崩溃后重复创建。
 - 规划时的旧值为空时不调用删除；旧值非空且仍与规划快照一致时，只有删除明确成功才继续。