feat: 顺运宝货运单同步 (#46)

顺运宝模块此前是骨架，「同步」点了提示"待接入"。5195 个蝦皮商品已经
进系统，但货运单（真实订单）一条都没有，后面的规格匹配无从谈起。

按接口契约（docs/admin/08，从 4 份 HAR 还原）实现：配置、登录（界面
手工输验证码）、会话缓存到 SQLite、按日期范围增量同步、落 syb_orders。

shopee_sku_id 绝不被同步覆盖。它是规格匹配的结果，顺运宝那边根本没有
这个值（只给 11 位商品ID，蝦皮規格ID 是 12 位）。同步写进去就是写空，
把人工攒的匹配成果洗掉且不报错。它只出现在 INSERT 列清单里，不在
DO UPDATE SET 里；repository 层和 service 端到端各有一个测试守着。

增量从「上次同步日期当天」重拉，不是第二天。created 筛选粒度是日期而
last_synced_at 精确到秒，从第二天拉会漏掉当天晚些时候创建的单且不报错。
宁可重复拉（upsert 幂等）也不能漏。中途失败不更新 last_synced_at，
否则下次跳过这段区间，漏的单永远补不回来。

日期运算用 UTC+8，不是 UTC。审查时从 HAR 确认 created 是当地时间：
抓包于 2026-07-28T03:31:45Z（= 11:31 UTC+8），同一响应里 created 是
"2026-07-28 10:37:59"；若它是 UTC 则等于 18:37 UTC+8，比抓包晚 7 小时，
订单创建于未来，不成立。用 UTC 算会在本地 00:00-08:00 把"今天"算成昨天，
当天早晨的单这轮拉不到。用 time.FixedZone 写死，不用 LoadLocation——
那要读系统 tzdata，Windows 默认没有，打包成 exe 会失败。

金额一律取 detail/listByStock 的值：08 §5.1 实测同一响应里 amtOrder
在列表接口是分、escrowAmount 却不是，单位不统一，取错差 100 倍。

迁移 v5 纯追加（syb_session、syb_sync_state、syb_orders.product_spec），
v1-v4 逐字未动，CheckSchema 覆盖新表新列。

会话有效性判断把「网络故障」和「明确未登录」的分类集中在 Client.do()
一处——网络抖一下就判定登出的话，验证码会弹个不停，还会丢掉有效会话。

测试全部用 httptest 假服务端，不打真实站点。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

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

@@ -243,6 +243,34 @@ amtOrder                      612.0
 差 66，应该是优惠。`[必须]` **不要用「明细合计 == amtOrder」做校验**，
 会误报。
 
+### 5.3 `created` 是 UTC+8，不是 UTC —— 日期范围查询最容易算错的地方
+
+`[必须]` 实测 `raw_data/shunyunbaoerp_stock_query.har`：
+
+```text
+HAR 记录的抓包时刻 startedDateTime   2026-07-28T03:31:45Z   （= 11:31:45 UTC+8）
+同一次请求响应里的 created           2026-07-28 10:37:59
+```
+
+`10:37:59` 作为 **UTC+8** 讲得通（比抓包时刻早 54 分钟，正常）。
+若把它当成 **UTC**，换算成 UTC+8 就是 18:37，比抓包时刻**晚 7 小时**——
+订单创建于尚未发生的未来，不成立。所以 `created` 是 UTC+8，不是 UTC。
+
+`[必须]` §4.2「按日期范围」的 `dvalue` 筛的就是这个 `created`，
+所以**换算"今天是哪一天"也必须用 UTC+8**，不能用 UTC 或本机系统时区
+（本机系统时区不一定是 UTC+8，取决于部署环境）。用 UTC 算的话，
+在 UTC+8 的 00:00–08:00 这段时间会把"今天"算成昨天，当天早晨创建的单
+这一轮同步拉不到——虽然下一轮的起始日期仍是"上次同步日"，范围会覆盖
+回来、不会永久丢单，但操作员当场点同步会以为同步坏了。
+
+`[必须]` 代码里固定用 `time.FixedZone("UTC+8", 8*60*60)`，不要用
+`time.LoadLocation("Asia/Shanghai")`——那个要读系统 tzdata，Windows 上
+默认没有，打包成 exe 后会在运行时报错。
+
+`[待定]` 只有一个样本（一次抓包）支撑这个结论，且没有拿到顺运宝官方
+文档确认。以后如果日期范围附近出现"该有的单没同步到"，先来这里核对
+这条结论是否仍然成立。
+
 ---
 
 ## 6. 货运明细
@@ -385,6 +413,8 @@ password: "0012345"    # ✓
 - [ ] 会话失效时服务端返回的**确切**形态（HTTP 码 / `code` / `msg` 文案）
 - [ ] 同一账号多处登录是否互踢
 - [ ] 验证码错误、密码错误分别返回什么，能否区分
+- [ ] `created` 是 UTC+8 这一条（见 §5.3）只有一次抓包支撑，
+      没有官方文档确认，也没有跨夏令时/时区配置的验证
 
 `[必须]` 最后两条影响错误提示的准确性：分不清「密码错」和「验证码错」的话，
 操作员会一直重输密码。