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>

tests/test_trading_api.py

@@ -85,6 +85,7 @@ class StubSiteInteractor:
         self.clear_calls = 0
         self.remove_calls: list[str] = []
         self.fail_with: Exception | None = None
+        self.browser_alive = True
 
     async def add_to_cart_payload(
         self,
@@ -129,6 +130,15 @@ class StubSiteInteractor:
             raise self.fail_with
         return {"removed": True, "item_id": item_id}
 
+    def browser_status(self) -> dict:
+        """/health 读的浏览器状态；browser_alive 可翻成 False 模拟掉线"""
+        return {
+            "started": True,
+            "alive": self.browser_alive,
+            "pending_checkout_tasks": [],
+            "detail": "连接正常" if self.browser_alive else "浏览器已掉线",
+        }
+
     async def close(self) -> None:
         """lifespan 收尾会调用；桩没有真实浏览器要关"""
 
@@ -168,6 +178,26 @@ def test_health_needs_no_token(client):
     body = response.json()
     assert body["data"]["status"] == "ok"
     assert set(body["data"]["auth"]) == {"rakuten"}
+    assert body["data"]["browser"]["alive"] is True
+
+
+def test_health_returns_503_when_browser_is_dead(client, stub_site):
+    """浏览器掉线 → 503，让容器 HEALTHCHECK 探到并触发重启
+
+    进程还活着、端口还通，但这个服务的所有站点操作都要靠那一个浏览器，它没了以后
+    每一单都会失败。返回 200 的话 HEALTHCHECK 永远绿灯，缺口就一直挂在那儿。
+    重启是安全的：网关侧任务绝不自动重投（docs/order-gateway.md §5）。
+    """
+    stub_site.browser_alive = False
+
+    response = client.get("/health")
+
+    assert response.status_code == 503
+    body = response.json()
+    assert body["success"] is False
+    assert body["code"] == 5006  # 与 BrowserDeadError 同码
+    assert body["data"]["status"] == "degraded"
+    assert body["data"]["browser"]["alive"] is False
 
 
 def test_health_does_not_probe_the_site(client, stub):