get_ws_url() should fail CLOSED for a named/managed daemon instead of scanning the default Chrome profile

[alipsky]

Summary

get_ws_url() (src/browser_harness/daemon.py:104) falls back to scanning the default Chrome profiles and then probing ports 9222/9223 whenever BU_CDP_URL/BU_CDP_WS is unset. For a named/managed daemon (one started via ensure_daemon(name=...) to drive a dedicated, isolated automation Chrome), that fallback is a footgun: on any daemon respawn where the env doesn't carry BU_CDP_URL, the daemon silently attaches to the user's daily-driver Chrome — or pops the chrome://inspect "Allow remote debugging" dialog on Chrome 136+.

Why it matters

A managed caller sets BU_NAME + BU_CDP_URL to pin a daemon to an isolated Chromium. But ensure_daemon() re-runs on every helper invocation, and on a respawn (parent restart, session teardown, zombie Chromium) a caller that carried only BU_NAME loses the pin. get_ws_url() then:

1. daemon.py:126 — scans PROFILES (the default user-data-dirs), attaching to the user's real Chrome;
2. daemon.py:154 — probes 9222/9223, silently attaching to whatever is listening there.

Today this only appears safe because Chrome 136+ gates the default profile behind the "Allow" dialog — i.e. it fails closed by accident. If the user has a pre-authorized debug Chrome on 9222, it drives it silently. This bit us as a real cross-project daily-driver breach (a downstream broker's ADR-022 firewall).

Proposed fix

An opt-in fail-closed guard so a managed daemon never falls back to local discovery. Either:

• honor a BU_NO_LOCAL_FALLBACK=1 env, or
• infer it when the daemon was started with a name (managed daemons are, by definition, pinned).

When set, and BU_CDP_URL/BU_CDP_WS is absent or unreachable, get_ws_url() should raise rather than reach the PROFILES scan (daemon.py:126) or the 9222/9223 probe (daemon.py:154) — a loud, honest failure that says "the pinned endpoint is gone, relaunch the session," never a silent attach to the user's Chrome.

Related

Distinct from #291 (that was a /json/version 404 fallback for the BU_CDP_URL happy path). This is about refusing the default-profile fallback entirely for pinned daemons.

[lisa0314]

I'd like to work on this.

My proposed first-pass scope is:

• add an opt-in BU_NO_LOCAL_FALLBACK=1 guard in get_ws_url();
• evaluate it after explicit BU_CDP_WS / BU_CDP_URL handling but before
  profile scanning and the 9222/9223 probes;
• raise an actionable error identifying the managed daemon and telling the
  caller to restore the pinned endpoint;
• add unit tests proving that local profile reads and port probes are never
  attempted when the guard is enabled;
• document the flag alongside the named-daemon connection flow.

I prefer an explicit flag initially to avoid changing the behavior of users
who use a non-default BU_NAME with a local browser.

Would you prefer the explicit flag, or should this be inferred automatically
whenever BU_NAME != "default"?