examples: browser-use connects too — verified, and a stale README claim fixed

[redbotster]

Summary

• New: examples/browser-use/ — an end-to-end proof that browser-use (a real third-party Python agentic browser framework, not built on Puppeteer or Playwright) connects to the bridge's CDP proxy and preserves the credential-fill guarantee, mirroring what register-login-act.mjs already proves for Puppeteer. Two processes: bridge_server.mjs (Node) starts a real bridge + login site; test_login.py (Python) connects browser-use and drives the whole flow.
• Fixed: the main README asserted "browser-use is Playwright-based, so it connects to the bridge unchanged" — true when written, false for current browser-use releases (they ship their own CDP client, cdp_use, not Playwright) — and this was never actually tested either way. Both READMEs now point at the real example and describe what's actually true.

What the new example confirms

1. Connectivity, with no special-casing needed. browser-use's connect() treats cdp_url as an HTTP endpoint to run /json/version discovery against — a discovery step browser-bridge doesn't serve (plain HTTP is a flat 404 by design). But browser-use's own code skips that discovery entirely whenever the URL already starts with ws, so pointing it straight at the bridge's printed URL just works — the same shape as browserWSEndpoint/connectOverCDP.
2. The gate still refuses what it should. browser-use calls Browser.grantPermissions on connect (Puppeteer/Playwright don't); the gate correctly refuses it (method_not_allowed, not on the allowlist) and browser-use handles the refusal without breaking the session.
3. The actual product claim. browser-use's own tab never touches the password field — the fill happens on a throwaway target the bridge creates itself. Afterward, that same tab (having typed nothing) loads a cookie-gated page and gets the authenticated view, proving the session landed in the shared browser context. The password never appears in the fill result or anything browser-use reads back.

One browser-use-side quirk noted in the README, not worked around since it doesn't affect the result: right after navigate_to(), browser-use's own get_tabs()/tab.url cache can still read about:blank even though the page really navigated (confirmed via a direct location.href read through browser-use's own CDP session).

Test plan

• Ran examples/browser-use/test_login.py against a real headless Chromium, 4 clean passes (exit 0, no password leak, login genuinely authenticated)
• pnpm verify (typecheck + typecheck:tests + full suite) — 276 passed, 6 skipped, no regressions
• node --check on the new .mjs file

🤖 Generated with Claude Code

https://claude.ai/code/session_01WqPU5z6K3maS9J6LrcsEic