实现付款后订单监控：真实探测 order.my.rakuten.co.jp 配送阶段

用真实订单号 306087-20260813-0863947697 探测 order.my.rakuten.co.jp（订单列表/
详情页），拿到真实 DOM 结构后实现 SiteInteractor.check_order_status：

- 详情页 URL 可直接从 site_order_id 构造（shop_id 是订单号第一段）
- 配送阶段用「进度条」组件的 4 个固定阶段（ショップ/出荷/配達店/配達完了），
  当前阶段的 class 带 -active-- 中缀，映射到 OrderState.SHIPPED/DELIVERED
- 查不到订单号、进度条解析不出新阶段都不算错误，交给轮询循环继续重试

runner.WorkerRunner 新增 _monitor_order 后台轮询：付款成功上报后以
asyncio.create_task 起后台任务（不阻塞主循环领下一单，因为 SiteInteractor 的
Playwright 操作全程持锁串行化），状态变化时用 terminal=False 追加 report；
新增 cancel_monitors() 在服务关闭时于 SiteInteractor.close() 之前收尾。

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

docs/order-gateway.md

@@ -324,7 +324,12 @@ trading 侧新增：
 1. 自动付款是否触发 3D Secure 或短信验证。若触发，这条路走不通，付款环节改为
    「下单到 `awaiting_payment` + 上报 `needs_human` 交人工」，其余环节不变。
 2. 下单确认页的实际应付金额、付款方式、付款期限、站点订单号各自在哪个字段。
-3. 订单列表页能否按商品 + 时间窗口可靠地反查出「这单下没下」（§5 的恢复核对依赖它）。
+3. 订单列表页能否按商品 + 时间窗口可靠地反查出「这单下没下」（§5 的恢复核对依赖它，
+   `verify.verify_on_site` 仍是恒返回 unknown 的桩）。2026-08-13 已经拿到过
+   `order.my.rakuten.co.jp` 的真实 HTML（用于实现付款后监控，见
+   `site_interact.py::check_order_status` / `_parse_order_status`），页面按
+   订单号能查到「注文番号」「配送阶段进度条」，但没有验证过按商品名/时间窗口
+   反查、也没有验证过多页/分页场景——对实现 §5 恢复核对有参考价值，不能直接复用。
 
 > **交易范围**：交易服务只覆盖乐天市场（rakuten）。ラクマ 的抓取仍在抓取服务里提供，
 > 但不进入交易链路——没有加购契约，也永不实现下单/付款/订单监控。