fix(orders): 修正发货功能关联的项目错误导致 storeId 为 0

- 发现并纠正之前误操作在错误项目 guilixu-taro 上的改动
- 恢复 guilixu-taro 项目中误改的文件，删除新增文件
- 明确实际工作项目为 xinlong-shop-taro，该项目已内置发货功能
- 解决 xinlong-shop-taro 中 openShipModal 调用 listShopStoreUser 未传 storeId 导致默认 0 的问题
- 修改 openShipModal 先调用 getMyClerk 获取 storeId，再传递给 listShopStoreUser 拉取本门店店员
- 默认选中当前登录人对应的店员，完善发货弹窗功能
- 警示跨项目操作时需确认准确项目路径，避免混淆同名 API 和项目目录

.workbuddy/memory/2026-07-17.md

@@ -63,3 +63,12 @@
   - 提交发货：`deliveryType=2`(商家送货)、`deliveryStatus=20`(待收货)、`deliveryTime`、`sendName/sendPhone`(店员)、`sendStoreId=storeId`、`deliveryUserId=店员id` → `PUT /shop/shop-order`。
   - 后端已在上一轮把 `sendStoreId`/`deliveryUserId` 落 `shop_order` + `shop_order_delivery`，此处字段对齐。
 - 验证：`tsc --noEmit --types webpack-env` 总报错仍 387（零新增）；orders 页仅剩 2 个既有报错（165 `fetchLatestOrders` 返回类型、169 `count` 隐式 any，均在未改的 `useNewOrderDetector` 调用块）。
+
+---
+## ⚠️ 重大纠正：正确项目是 xinlong-shop-taro，不是 guilixu-taro
+- 用户最终明确：商家端发货/门店相关功能在 **`/Users/gxwebsoft/VUE/xinlong-shop-taro`**，前面整段记的 `guilixu-taro` 改动**全改错项目**了。
+- **已在 guilixu-taro 还原**（git 仓库）：`git checkout --` 还原 5 个跟踪文件（model/index.ts、app.tsx、center/index.tsx、orders/index.tsx、user.tsx）；`rm` 删除 2 个新建文件（contexts/ClerkContext.tsx、hooks/useClerk.ts）。未动的 `pages/index/index.scss` 是仓库原有未提交改动，保留。
+- **xinlong-shop-taro 才是真项目，且早已内置发货功能**：`orders/index.tsx` 已有 `OpType='ship'` 的「发货」+ `saveShopOrderDelivery` + `listShopStoreUser` + 发货弹窗；`user.tsx` 已有 `getMyClerk()` 取 `storeInfo`（含 `.storeId`）用于"门店中心"判断。
+- **真正的 `storeId=0` bug 根因**：`xinlong-shop-taro/src/pages/store/orders/index.tsx:465` 的 `openShipModal` 调 `listShopStoreUser()` **没传 storeId**（默认 0），即用户最初报的 `?storeId=0`。
+- **已修（xinlong-shop-taro）**：`openShipModal` 内先 `getMyClerk()` 取 `storeId`，`listShopStoreUser({storeId})` 拉本门店店员；并默认选中 `userId === 当前登录人 userId` 的店员（`setSelectedClerkId(match.id)`）。`tsc --noEmit --types webpack-env` 该文件零新增报错（仅 162/208/212 三个项目既有错误，均在我未改动区域）。
+- **教训**：跨项目时先用 glob/find 在多个候选项目里确认"哪个项目有该功能源码"，再动手；不要凭域名/习惯默认锁定一个项目。本次因 `guilixu-taro` 与 `xinlong-shop-taro` 命名相近、且前者恰有 `getMyClerk` 等同名 API 而误判。