fix: poll health while waiting for proxy readiness

[dimaria1122]

中文

背景

我们在 macOS 上使用 web-access 连接主 Chrome 时，check-deps.mjs 在等待 proxy 就绪的阶段会循环请求 /targets。问题在于 /targets 并不是纯粹的健康检查：它会进入 cdp-proxy.mjs 的正常请求路径，并在尚未完成授权时再次触发 connect()。

在我们的复现场景里，这会把一次正常的 Chrome 远程调试授权，放大成连续多次的连接尝试，用户侧表现为短时间内收到一串重复授权请求。

修改内容

• 把等待 proxy 就绪的逻辑提取成 waitForProxyConnection() helper
• 等待阶段只轮询 /health
• 只有 /health.connected === true 时才判定 proxy 已 ready，不再用 /targets 做探活

为什么这样改

/health 已经足够表达 check-deps 需要的状态：proxy 是否连上浏览器。

相比之下，/targets 会触发更深的请求路径；在浏览器授权尚未完成时，重复请求它会制造额外的连接噪音，但不会带来更多有效信息。

Test Plan

• 新增单元测试，验证等待逻辑只轮询 /health
• 运行 node --test tests/check-deps-wait.test.mjs
• 运行 node scripts/check-deps.mjs --browser chrome，验证脚本可正常返回 ready

---

English

Background

When using web-access on macOS against the main Chrome instance, check-deps.mjs currently polls /targets while waiting for the proxy to become ready. The problem is that /targets is not a pure health check: it enters the normal request path in cdp-proxy.mjs and can trigger another connect() while browser authorization is still pending.

In our repro, that turned a single normal Chrome remote-debugging approval into a burst of repeated connection attempts. On the user side, it showed up as multiple authorization prompts in a short time.

Changes

• extract the proxy wait logic into a small waitForProxyConnection() helper
• poll only /health during the wait phase
• consider the proxy ready only when /health.connected === true, instead of probing readiness through /targets

Why this change

/health already exposes the exact state check-deps needs: whether the proxy is connected to a browser.

By contrast, /targets exercises a deeper request path. While authorization is still pending, repeatedly hitting it adds connection noise without providing better readiness information.

Test Plan

• add a unit test asserting the wait loop polls /health only
• run node --test tests/check-deps-wait.test.mjs
• run node scripts/check-deps.mjs --browser chrome and verify it returns ready