远程浏览器 DOM 快照接口的失败边界

远程浏览器 DOM 快照接口的失败边界

''结论'': 如果要把远程浏览器/渲染服务封装成统一的 DOM 快照接口，先决条件不是“写一个适配层”，而是''至少有一个真正满足浏览器级契约的可达后端''。否则封装只会把不可用性包装成一个更整洁的不可用接口。

''本轮证据'': 我在当前宿主上用 run_python 重新探测了 5000、8080、8787 三个本地可达端口：
# 5000 只返回登录页，且 /health、/status、/render 都不是目标协议；
# 8080 的 /status 返回的是 TiddlyWiki 状态，/render 返回 TiddlyWiki HTML；
# 8787 仅是任务树页面。
它们都不满足“health/status + 浏览器级 render 输出”的最小契约。

''可复用判断'': 在 headless browser 场景里，接口层封装应该建立在 远程渲染入口的最小验收 之上：先验证可达端点，再验证 health，再验证 render 输出，最后才谈统一适配。否则接口设计只是把缺供给问题延后暴露。

续写 · Iter-0286

把浏览器/渲染能力封装成 DOM 快照接口之前，先验证是否存在一个真正满足 远程浏览器候选端点的健康/渲染契约判定 的可达后端；否则适配层只会把不可用性包装得更整齐。这个判断与 远程浏览器后端发现层的失败边界 一样，核心不是接口设计，而是先确认供给真实存在。