feat(browser): connect CDP to the real user profile

[bobleer]

What

Lets browser control attach to the Chrome/Edge the user already has open — existing tabs, existing logins — instead of launching an empty managed profile. The browser owns the consent: a persistent switch on its own settings page, plus a per-connection approval dialog.

Two commits:

1. feat(browser): connect CDP to real user profiles — discover the browser-level endpoint from DevToolsActivePort in the browser's normal user-data dir, connect over that WebSocket, and expose an Enable default CDP action in Settings.
2. fix(browser): open the real remote debugging page for default CDP — the setup flow above never actually worked; see below.

The bug in commit 1

The setup step spawned the browser with the settings URL on the command line:

/Applications/Google Chrome.app/Contents/MacOS/Google Chrome  chrome://inspect/#remote-debugging

Chromium drops chrome:// URLs handed to it on the command line and silently substitutes chrome://newtab/. Reproduced on Chrome 151 with chrome://version, chrome://settings and chrome://inspect — all three land on the New Tab Page. So the browser popped open on a blank tab, there was no switch to tick, and the 60s setup wait always timed out with "the switch was not detected".

Fix

• macOS — route the URL through the browser's own AppleScript open location handler, which is not subject to that filter. Verified opening chrome://inspect/#remote-debugging correctly.
• Windows / Linux — no equivalent entry point. They no longer open a throwaway tab that pretends to have worked; they start the browser only if it is not running and hand the URL back to the user, reported as a distinct requires_manual_user_profile_setup status that carries setupUrl so the UI can show it.

Also

chrome://inspect is not localized — it stays English even under --lang=zh-CN. The prompts said "勾选『允许远程调试』", which appears nowhere on that page; they now quote the real label, "Allow remote debugging for this browser instance".

And the browser-control settings copy leaked internal vocabulary ("guarded CDP", "real user profile", "empty profile"). Rewritten in plain language across en-US / zh-CN / zh-TW.

Verified

On Chrome 151, in throwaway profiles:

• devtools.remote_debugging.user-enabled: true in Local State → server on 9222 + DevToolsActivePort written to the user-data dir. The detection path in commit 1 is correct.
• In that mode the HTTP endpoints (/json/version, /json/list) return 404; only the browser WebSocket from DevToolsActivePort works — which is what the client uses.
• The switch exists and is visible by default: #remote-debugging-enabled, "Allow remote debugging for this browser instance".

Build/tests: cargo check -p bitfun-desktop -p bitfun-core -p bitfun-services-integrations, cargo test -p bitfun-services-integrations --features browser-control (9 passed), tsc --noEmit (0 errors). Setup flow confirmed working end to end on macOS by the reporter.