feat: 档口入库码后台批量回写 (#246)

docs/admin/03-data-model.md

@@ -1022,7 +1022,7 @@ CREATE UNIQUE INDEX idx_client_assignment_current
 `ai_spec_match_decisions`。Admin 重启把未完成明细改为 `interrupted` 并完成批次计数，已经
 成功写入的 `spec_mappings` 不回滚。
 
-## 17. `syb_inner_code_records` 档口入库码记录（MySQL v23，软删除 v24）
+## 17. `syb_inner_code_records` 档口入库码记录（MySQL v23，软删除 v24，后台回写 v25）
 
 档口入库码使用一张业务表完成导入、匹配、回写和异常恢复。Excel 只是导入载体，系统
 不保存原文件、文件哈希，不再拆批次表或尝试记录表。
@@ -1036,14 +1036,19 @@ CREATE UNIQUE INDEX idx_client_assignment_current
   `source_duplicate_count` 保存合并前的 Excel 源行数，只用于展示和审计，不阻止确定性匹配。
 - `stock_id/detail_id` 和 `syb_*`、`purchase_*`、`remote_inner_code` 保存最近一次远端
   规划快照，不替代 `syb_orders`，也不修改采购数据。
-- 状态固定为 `pending/ready/applying/updated/already_filled/skipped/failed/needs_check`。
-  重复导入可以重置尚未完成的记录，但不得覆盖 `updated`、`already_filled`、`applying`
-  或 `needs_check` 的远端结果和审计状态。
+- 状态固定为 `pending/ready/queued/applying/updated/already_filled/skipped/failed/needs_check`。
+  `queued` 只表示尚未发送远端请求，`applying` 才表示已经进入逐条远端处理。重复导入可以
+  重置尚未完成的记录，但不得覆盖 `queued`、`updated`、`already_filled`、`applying` 或
+  `needs_check` 的远端结果和审计状态。
 - `created_by_user_id` 记录首次导入账号，`applied_by_user_id` 记录实际回写账号；时间字段
   使用 UTC ISO 8601。用户只停用不物理删除，因此外键不会阻塞账号生命周期。
 - v24 增加 `deleted_at`、`deleted_by_user_id`。正常列表、统计、匹配和新的回写入口只读取
   未删除记录；删除不改变业务状态，也不撤销顺运宝远端值。在途 `applying` 的最终结果仍
   写回同一条隐藏记录，保证远端结果审计不会丢失。
 - 重新导入同一业务键会恢复软删除记录：`pending/ready/skipped/failed` 重置为
-  `pending` 并清空旧规划；`applying/updated/already_filled/needs_check` 保留状态和远端
+  `pending` 并清空旧规划；`queued/applying/updated/already_filled/needs_check` 保留状态和远端
   审计。后一组状态若导入的 `inner_code` 已变化则拒绝恢复，交由人工核对。
+- v25 增加 `apply_batch_id`、`apply_queued_at` 和批次状态索引。批次仍记录在同一业务表，
+  不新增批次表：提交时所选 `ready` 记录必须在同一事务内全部转为 `queued`；后台每次最多
+  读取 20 条并逐条领取为 `applying`。页面按 `apply_batch_id` 聚合当前批次进度。Admin
+  重启时，`queued` 恢复为 `ready` 且不会自动写远端，`applying` 转为 `needs_check`。

docs/admin/05-ui-specification.md

@@ -137,7 +137,11 @@
   避免操作员看不到将被处理的记录。
 - `[必须]` 每页条数只控制读取和展示，不能充当外部写操作的安全上限。档口入库码
   只读匹配允许处理当前页全部选中记录，内部每次最多读取 100 个顺运宝货运单；
-  回写会修改远端数据，继续使用独立的单次上限 20。
+  回写允许提交当前页全部选中记录，页面立即返回。后台每次最多从数据库读取 20 条，
+  但远端仍逐条执行写前核验、最多一次写入和写后复核。
+- `[必须]` 档口入库码后台回写进度使用文字和原生 `<progress>` 同时表达，并提供普通
+  GET 刷新链接；不只依赖颜色，也不使用脚本自动轮询。页面至少显示排队中、回写中、
+  成功、失败和需核对数量。
 - `[建议]` 不做 `1 2 3 … N` 这种页码列表。页数一多列出来没有意义，
   操作员应该靠筛选定位，不是靠翻页数页码。
 

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

@@ -426,6 +426,9 @@ GET /am/stock/detail/updateDetailCode?t=0&id={stockID}&detailId={detailID}&code=
 - 每条写入前重新调用 `listByStock`，核对 stock/detail、规格、采购平台、采购单号和规划时
   的旧值；写入后再次读取，只有 `innerExpCode` 与目标一致才标为已回写。
 - “重新核对”只调用 `listByStock`，绝不能再次调用上述两个写接口。
+- 页面提交数量不限制为 20 条。所选记录先在 MySQL 同一业务表中进入 `queued`，HTTP 请求
+  随即返回；后台每次最多读取 20 条，再逐条执行上述远端门禁。Admin 重启不会自动继续
+  未开始的真实远端写入：`queued` 恢复为可回写，`applying` 转为需核对。
 
 ---