feat: add remote browser CDP control support

[diegosc78]

Summary

Add support for connecting to remote CDP-compatible browsers (e.g., Obscura) instead of launching a local browser instance.

Changes:

• Add --browser-control-url flag to specify remote CDP WebSocket URL
• Add --delegate-stealth flag to skip local stealth patching when remote browser handles anti-detection features
• Update BrowserOpts to support remote CDP connection
• Add configuration options in config.yaml for remote browser setup

Why

This enables using managed browser services like Obscura as drop-in replacements for local Chrome/Chromium instances while maintaining full CDP compatibility.
Obscura https://github.com/h4ckf0r0day/obscura may offer better performance

Testing

• make test
• make lint
• make test-integration (only for browser, proxy, captcha, or live-engine changes)

Checklist

• I linked the related issue or explained why there is none.
• I updated docs or examples for changed user-facing behavior.
• I kept unit tests deterministic and free of browser/network dependencies.
• I removed secrets, proxy credentials, and private logs from examples.

[karust]

Thanks for the PR - I like the idea!
Remote CDP support could give users more control over browser infrastructure.

I tested three remote CDP backends:

• Obscura: connects via its fixed WebSocket endpoint, but searches time out waiting for result selectors. It also reports unsupported Page.stopLoading and Page.close calls. We need better diagnostics to distinguish navigation failure, an interstitial/block page, and renderer/CDP incompatibility.
• Lightpanda: connects, but fails before navigation because it does not implement Emulation.setLocaleOverride. The current delegate_stealth path still applies locale, timezone, UA, device and header overrides, so it is not full delegation.
• Chrome CDP: works. A search succeeded when using Chrome's complete webSocketDebuggerUrl. Note that native Chrome uses ws://127.0.0.1:9222/devtools/browser/<browser-id>, where the browser ID changes on restart and is available from http://127.0.0.1:9222/json/version.

The feature definitely makes sense. It just needs clearer compatibility requirements before we can call it generic remote CDP support.