fix(rock): 修复空闲库存为0时误将已分配订单判定为补货中并拦截发货的严重漏洞

1. 根因修复(状态机死锁)：当一笔订单分配了池中最后一个可用Token后，空闲库存降为0。原PrepareDelivery仅检查AvailableStock<=0，导致已锁定Token的订单在发货校验时被误判为'库存补充中'并硬性拦截发货；
2. 逻辑重构：PrepareDelivery增加已预占Token识别，若当前订单已持有using或bound状态的专属Token，直接豁免空闲库存校验，放行扫码与发货；
3. 协议对齐：在ClaimTokens与RefreshToken中补全Origin与Referer请求头；
4. 单元测试与方案文档：新增TestRockProvider_PrepareDelivery_ZeroStockWithAssignedToken用例，5项Rock专项单测与全量Service测试100%全绿通过，方案文档追加7.5节证据与复盘记录。

docs/Rock发货平台代理接入与库存风控实施方案.md

@@ -401,5 +401,38 @@ Content-Type: application/json
 3. **FulfillID 兜底流**：官方单号提取优先从 `token.upstream_fulfill_id` 读取，若兑换后无单独 ID 则平滑兼容；
 4. **编译与单测**：全量单元测试与编译均已 100% 通过。
 
+### 7.5 “提货页补货中与发货报错”死锁漏洞排查记录（基于自身的补货中, 但是后台正常.har 铁证）
+
+#### 证据分类审计表
+| 维度 | 内容详情 | 确信度 |
+| :--- | :--- | :--- |
+| **已知 (Known)** | 1. 用户反馈：自己的发货页面一直提示“补货中”，后台发货一直报错拦截，但上游 0666.pro 平台却可以正常发货；<br>2. 抓包证实 Token 152317 绑定正常且在上游已成功发货（账号：`屛堃`，UID：`3640883661`）；<br>3. 数据库中订单 33 已完成发货，可用 Token 数量正好归零 (`AvailableStock = 0`)。 | **100% (有 HAR 报文与 DB 记录双重佐证)** |
+| **未知 (Unknown)** | 为何订单明明已分配 Token 且绑定成功，提货页与发货接口仍强制判定为不可发货并提示“补货中”？ | **已探明** |
+| **目标 (Goal)** | 修复 `PrepareDelivery` 状态机判定，订单一旦成功预占分配 Token，无论池子空闲库存是否为 0，均允许正常进入扫码与发货履约流程。 | **100% 达成** |
+
+#### 致命逻辑盲区根因解构：
+1. **死锁链条**：
+   - 当一笔订单分配了池中最后一个 Token 后，数据库中 `status = 'available'` 的空闲 Token 数量变为 `0`；
+   - 买家扫码授权后，提货页轮询或点击发货，外层均调用 `PrepareDelivery` 进行发货前瞻校验；
+   - 原代码无条件执行：
+     ```go
+     if stats.AvailableStock <= 0 {
+         return &DeliveryOrderState{CanShip: false, CannotShipReason: "当前商品库存补充中..."}
+     }
+     ```
+   - 原逻辑**完全忽略了当前订单其实早就成功预占了专属 Token**！
+   - 导致提货页直接弹窗横幅提示“当前商品库存补充中”，并在买家点击发货时被 `if !info.CanShip` 硬性拦截报 400 错误！
+   - 此时由于上游 0666.pro 已经完成微信扫码绑定，用户前往 0666.pro 官方后台点击发货自然能够成功，造成了“自己系统报补货中，但官方后台发货正常”的假象。
+2. **修复落地**：
+   - 在 `PrepareDelivery` 中增加专属已占库存识别：如果当前订单号已存在 `using` 或 `bound` 状态的 Token，判定为库存已锁定，豁免空闲库存校验；
+   - 针对未分配 Token 的新订单，在空闲库存不足时若开启了自动采购，即刻触发异步补货巡检；
+   - 在 `ClaimTokens` 与 `RefreshToken` 中补齐 `Origin` 与 `Referer` 头。
+3. **回归测试门禁**：
+   - 新增单元测试 `TestRockProvider_PrepareDelivery_ZeroStockWithAssignedToken`：
+     - 断言 1：空闲库存为 0 时，新订单被正确拦截并提示“库存补充中”；
+     - 断言 2：空闲库存为 0 时，已分配 Token 的订单必须 100% 允许正常发货（`CanShip = true`）。
+   - 包含新增用例在内的 5 项 Rock 专项测试与全量 service 测试全部 100% PASS。
+
+