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_worker_runner.py

@@ -20,7 +20,7 @@ from typing import Any
 
 import pytest
 
-from app.shared.errors import CheckoutBlockedError, OrderGuardError
+from app.shared.errors import BrowserDeadError, CheckoutBlockedError, OrderGuardError
 from app.shared.task_state import OrderState, TaskStatus
 from app.trading.worker import verify
 from app.trading.worker.evidence import EvidenceStore
@@ -352,6 +352,41 @@ async def test_checkout_blocked_becomes_needs_human(
     assert "风控" in terminal["detail"]
 
 
+# ---- 浏览器掉线 → needs_human（不是 failed）----
+
+
+async def test_browser_dead_becomes_needs_human(runner: WorkerRunner):
+    """执行途中浏览器掉线 → BrowserDeadError → 转 needs_human
+
+    两件事同时被这个用例守着：
+
+    1. BrowserDeadError 是 AppError 的子类，能被 _execute_with_renewal 接住并**上报**。
+       不是 AppError 的话它会一路飘到主循环的兜底日志里，任务一次都不上报，网关侧
+       要干等整个 lease_ttl 才被 sweep 置 stale。
+    2. 结论是 needs_human 而不是 failed——`except BrowserDeadError` 必须排在
+       `except AppError` 前面，顺序反了这个断言就会挂。浏览器是在动作中途没的，
+       站点侧生效与否无从判断，不能给上游一个「明确失败」的结论。
+    """
+
+    async def _noop(task):  # noqa: ANN001
+        return None
+
+    async def _browser_died(task):  # noqa: ANN001
+        raise BrowserDeadError("pay：浏览器已掉线，本单是否已提交无法判断，需人工核对订单列表")
+
+    runner._site.add_to_cart = _noop  # type: ignore[assignment]
+    runner._site.verify_cart = _noop  # type: ignore[assignment]
+    runner._site.enter_checkout = _browser_died  # type: ignore[assignment]
+    _set_site_clear(runner._site, {"removed_count": 0, "cart_count": 0})
+
+    await runner.handle(_make_task(task_id="t1"))
+
+    gateway: FakeGateway = runner._gateway_for_test  # type: ignore[attr-defined]
+    terminal = gateway.last_terminal_report()
+    assert terminal["terminal_status"] == TaskStatus.NEEDS_HUMAN
+    assert "掉线" in terminal["detail"]
+
+
 # ---- ラクマ 不在交易范围 → needs_human ----