feat(trading): 浏览器掉线兜底——任务边界自愈重建，中途掉线转 needs_human

SiteInteractor 的 Chromium 是进程级单例，此前启动后即假定永远活着：全仓唯一的
is_connected() 探活在 scraping 侧，交易侧既不探活也不重启。容器里 Chromium 崩溃
是有真实前提的（/dev/shm 不足、OOM kill、seccomp 挡 sandbox，docker-compose.yml
里已有相关注释），一旦发生，进程还活着但之后每一单都会失败，且 /health 恒返回
ok，restart: unless-stopped 永远不会被触发。

更隐蔽的一条：clear_cart / enter_checkout / pay 等处的 new_page()、context.request
写在 try 之外，掉线抛的 TargetClosedError 不是 AppError，会穿过 runner 的
except AppError 落到主循环那个只记日志的兜底里——任务一次都不上报，网关侧要干等
整个 lease_ttl（默认 300s）才被 sweep 置 stale。clear_cart 是 execute() 的 step 0，
浏览器死时最先撞上的正是它。

分三层处理：

- 任务边界自愈。_launch() 从 start() 抽出，_context_options() 统一 context 参数
  （重建必须与启动完全一致，指纹漂移就是一次风控事件）；_refresh_context_if_stale
  改名 _ensure_context_ready()，先探活重建再做原有的 storage_state mtime 检查
  （顺序不可换，mtime 重建要用 self._browser）。重建前丢弃 _checkout_pages 里的
  残留确认页并记 warning——那些 Page 已随浏览器一起没了。

- 中途掉线不重建，抛 BrowserDeadError（新增，5006）。新增 _new_page() 与
  _request() 两个壳收口裸异常；_request() 只在确认浏览器真死了时才改写异常，
  站点 5xx 这类正常业务失败原样抛出。submit_order / pay 入口用
  _require_live_browser() 直接拒绝：这两步复用 enter_checkout 留存的 Page，
  重建救不回服务端订单草稿，而 pay 跑的时候订单已经真的提交了。顺带修掉一个
  误诊——浏览器死时 submit_order 原先报「未找到确认按钮」，把「浏览器崩了」
  说成「站点改版了」，两者的处置方式完全不同。

- runner 把 BrowserDeadError 转 needs_human 而非 failed，except 分支排在
  except AppError 之前（子类，顺序反了就报 failed）。掉线发生在动作中途，
  站点侧生效与否无从判断，不能给上游「明确失败」的结论。

/health 暴露 browser 状态，掉线时 degraded + HTTP 503 + code 5006，让
Dockerfile.trading 的 HEALTHCHECK 探到并重启容器。重启不会导致重复下单：网关侧
任务绝不自动重投，租约过期只置 stale 等人工 reclaim（docs/order-gateway.md §5），
重启只是恢复领新任务的能力。启动窗口期 started=False 不算掉线。

README 错误码表补 5005（此前遗漏）与 5006。

新增 15 个用例覆盖探活三态、is_connected() 自身抛错、边界重建/不重建/丢弃残留页/
重建失败、两个包装壳的分支、submit/pay 拒绝、runner 转 needs_human、/health 503。
真实 Chromium 崩溃无法在离线测试里制造，用例模拟的是 is_connected() 返回 False
这个唯一可观测信号，覆盖的是代码对该信号的反应而非崩溃本身；容器 HEALTHCHECK
真的触发重启这条链路尚未实跑验证。

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

README.md

@@ -125,7 +125,7 @@ PC UA 在搜索页、详情页、店铺页上都能拿到完整模板。因此
 
 | 接口 | 说明 |
 | --- | --- |
-| `GET /health` | 健康检查，含乐天账号登录态（只读缓存，不打站点） |
+| `GET /health` | 健康检查，含乐天账号登录态（只读缓存，不打站点）与浏览器连接状态；浏览器掉线时返回 **503** |
 | `POST /api/auth/status` | 查询登录态，默认真实探测一次 |
 | `POST /api/auth/login` | 按 `account.yaml` 自动登录（已登录则跳过；撞验证码要人工接管） |
 | `POST /api/auth/reload` | 人工重新登录后免重启换上新 cookie |
@@ -639,6 +639,8 @@ trading 加购时的字段选择策略：多规格挑第一个非售罄的 varia
 | 5002 | 加购失败（交易服务） | 400 |
 | 5003 | 下单失败（交易服务） | 400 |
 | 5004 | 下单安全闸门未通过：未显式确认或金额超上限（交易服务） | 400 |
+| 5005 | 结算被站点风控拦截：session upgrade / 3DS 等需人工验证（交易服务） | 400 |
+| 5006 | Playwright 浏览器已掉线（交易服务；也是 `/health` degraded 时的 code） | 400 / 503 |
 | 6001 | 任务不存在（网关） | 404 |
 | 6002 | 租约无效：不是持有者、已过期或任务已终结（网关） | 409 |
 | 6003 | 任务状态不允许该操作（如对已终结任务 reclaim）（网关） | 409 |
@@ -649,6 +651,10 @@ trading 加购时的字段选择策略：多规格挑第一个非售罄的 varia
 错误码在两站、三个服务之间通用。ラクマ 链路不会出现 `3002`（无反爬拦截行为）
 与 `4002`（无子站跳转）；`5xxx` 只会来自交易服务——抓取服务全程匿名，不会有登录态问题。
 `5001` 与 `5004` 都标记为不可重试：前者要人工重新登录，后者要调用方改入参。
+`5005` 与 `5006` 同样不可重试，且都转 `needs_human`：前者是站点主动要求人工验证，
+后者是浏览器在动作中途没了、站点侧生效与否无从判断——下单不可逆，这种时候必须
+停下来等人核对，不能赌。浏览器在**任务边界**掉线不会产生 `5006`，交易服务会就地
+重建一套继续跑；重建失败或掉线发生在一次调用途中，才抛这个码。
 `6xxx` 只会来自网关：`6001`–`6004`（下单任务通道）全部标记为不可重试——任务编排侧
 重试无意义，部分场景（如租约过期）重试可能变成重复下单；`6005`–`6006`
 （账号只读查询通道）**可以重试**——查询只读，重发没有副作用