fix: 使用原始SKU辅助档口匹配 (#259)

docs/admin/03-data-model.md

@@ -131,6 +131,8 @@ v26（#254）新增 `purchase_spec_resolutions`，用一张表保存采购执行
 幂等身份和最终规格决策；不修改历史 SQLite migration，也不覆盖 PDD 商品主数据。
 v27（#250）为 `syb_inner_code_records` 增加可空 JSON 字段 `remote_items_json`，保存
 多件商品逐个入库码对应的远端明细、来源和动作状态；仍不拆分新的业务表。
+v28（#259）为该表增加可空 `source_sku_raw`，保留 Excel 原始 SKU，供匹配阶段与
+顺运宝 `sku/variationSku` 做边界去空白后的精确比较。
 
 **v3 为什么丢弃旧 `sku_mappings` 数据（见 #20）：** 新主键需要 `pdd_option_key`，
 这是 Go 的 `service.OptionKey()` 用 `json.Marshal` 算出来的规范化键，SQL 语句
@@ -1027,7 +1029,7 @@ CREATE UNIQUE INDEX idx_client_assignment_current
 `ai_spec_match_decisions`。Admin 重启把未完成明细改为 `interrupted` 并完成批次计数，已经
 成功写入的 `spec_mappings` 不回滚。
 
-## 17. `syb_inner_code_records` 档口入库码记录（MySQL v23，软删除 v24，后台回写 v25，逐件检查点 v27）
+## 17. `syb_inner_code_records` 档口入库码记录（MySQL v23，软删除 v24，后台回写 v25，逐件检查点 v27，原始 SKU v28）
 
 档口入库码使用一张业务表完成导入、匹配、回写和异常恢复。Excel 只是导入载体，系统
 不保存原文件、文件哈希，不再拆批次表或尝试记录表。
@@ -1061,6 +1063,10 @@ CREATE UNIQUE INDEX idx_client_assignment_current
   不再接收聚合字符串：原商品明细承载一个码，额外单件使用数量 1、价格 0 的占位明细。
   JSON 数组按单件码保存 `detail_id/source/title/status` 检查点；新增或写入结果未知时立即
   转为 `needs_check`，重启后只读扫描整张货运单，不自动重发请求。
+- v28 增加可空 `source_sku_raw VARCHAR(500)`。数据库保留 Excel 单元格原文；匹配时仅
+  去除两端空白后，与规格候选的 `sku` 或 `variationSku` 完全相等比较。唯一命中时它是
+  高优先级确定性证据；重复命中或与档口货号唯一证据冲突时停止自动选择。缺失或零命中
+  继续使用原档口货号规则，不做去 `#`、包含匹配或短货号猜测。
 
 ## 18. `purchase_spec_resolutions` 采购运行时规格解析（MySQL v26）