fix(browser): thread the preferred profile through readiness and status checks

[Benjamin-eecs]

Description

With two or more profiles connected and a default set via opencli profile use, every command relying on the readiness pre-check failed with Multiple Browser Bridge profiles are connected, and doctor reported FAIL claiming no default was selected (#2259). The readiness path dropped preferredContextId before it reached the daemon: /status only ever received contextId, so the daemon-side arbitration /command already exercises never ran for health checks.

The preferred id now rides the same params as the explicit one through the readiness path into the /status handler, which passes it to resolveExtensionConnection exactly as /command does. doctor threads the resolved selection too, so an explicit OPENCLI_PROFILE is likewise diagnosed as the profile it names. Arbitration semantics are unchanged (#2073): a stale default still falls back or fails fast rather than pinning readiness.

The diagnosis and the fix plan are @lyc10031's, laid out in the issue; this implements them with tests.

Related issue: Closes #2259

Type of Change

• 🐛 Bug fix
• ✨ New feature
• 🌐 New site adapter
• 📝 Documentation
• ♻️ Refactor
• 🔧 CI / build / tooling

Checklist

• I ran the checks relevant to this PR
• I updated tests or docs if needed
• I included output or screenshots when useful

Documentation (if adding/modifying an adapter)

• Added doc page under docs/adapters/ (if new adapter)
• Updated docs/adapters/index.md table (if new adapter)
• Updated sidebar in docs/.vitepress/config.mts (if new adapter)
• Updated README.md / README.zh-CN.md when command discoverability changed
• Used positional args for the command's primary subject unless a named flag is clearly better
• Normalized expected adapter failures to CliError subclasses instead of raw Error

Screenshots / Output

Live, two profiles connected (the real Chrome profile fvqtde6b plus a second synthetic extension connection), default set to fvqtde6b. Before, on v1.8.6:

$ opencli browser main state
✖  Multiple Browser Bridge profiles are connected
✖  Hint: Select one with --profile <name>, OPENCLI_PROFILE=<name>, or opencli profile use <name>.
Run opencli profile list to see connected profiles.

$ opencli doctor
opencli v1.8.6 doctor (node v26.0.0)

[OK] Daemon: running on port 19825 (v1.8.6)
[MISSING] Extension: not connected

Profiles:
  • fvqtde6b: connected v1.0.22, default
  • zvyfake1: connected v1.0.22
[FAIL] Connectivity: failed (Multiple Browser Bridge profiles are connected)

Issues:
  • Multiple Chrome profiles are connected to the daemon, but no default profile was selected.
  Run opencli profile list, then opencli profile use <name>, or pass --profile <name>.
  • Browser connectivity test failed: Multiple Browser Bridge profiles are connected

After, same setup on this branch:

$ opencli browser main state
URL: about:blank

url: about:blank
title: 
viewport: 1280x568
---
---
interactive: 0 | iframes: 0

$ opencli doctor
opencli v1.8.6 doctor (node v26.0.0)

[OK] Daemon: running on port 19825 (v1.8.6)
[OK] Extension: connected (v1.0.22)

Profiles:
  • fvqtde6b: connected v1.0.22, default
  • zvyfake1: connected v1.0.22
[OK] Connectivity: connected in 0.1s

Everything looks good!

The daemon-level flip on the same run: /status with no params keeps profileRequired: true; ?preferredContextId=fvqtde6b returns profileRequired: false with contextId: fvqtde6b; a stale preferred with two live profiles stays true, keeping the #2073 fallback semantics.

Every touched source file is individually pinned: reverting any one of the seven alone fails at least one named test, with the daemon-side /status forwarding pinned end-to-end by a real-daemon e2e case in tests/e2e/daemon-transport.test.ts. The six touched suites pass 106 / 106 (npx vitest run over src/browser.test.ts, bridge-readiness, daemon-client, doctor, daemon, and tests/e2e/daemon-transport); typecheck, both lint gates and doc coverage pass; cli-manifest.json unchanged.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.