[Feature]: Allow configuring remote Playwright browser endpoint for browser_use tool

## Summary

Allow users to configure a custom remote Playwright browser endpoint (e.g., a browserless service) for the `browser_use` tool, instead of forcing a local browser installation. This lets users share a single headless browser instance across multiple projects, saving resources and avoiding platform-specific installation issues (e.g., Playwright incompatibility on Ubuntu 26.04).

## Component(s) Affected

- [x] Core / Backend (app, agents, config, providers, utils, local_models)
- [x] Console (frontend web UI)
- [ ] Channels (DingTalk, Feishu, QQ, Discord, iMessage, etc.)
- [x] Skills
- [ ] CLI
- [x] Documentation (website)
- [ ] Tests
- [ ] CI/CD
- [ ] Scripts / Deploy

## Problem / Motivation

- Many projects need headless browsers. Running a separate browser for each project wastes resources.
- I already deployed a **browserless** instance (supports Puppeteer/Playwright) and have multiple other projects connected to it. I want QwenPaw to connect to that same instance.
- Installing Playwright via pip/system packages is fragile:
- Upgrades or system updates can break the installation.
- Ubuntu 26.04 currently has incompatibilities that prevent Playwright from installing correctly.
- Installing a full Chrome/Chromium just for automation is unnecessarily heavy and bloated.
- Users who run QwenPaw in resource-constrained environments (small VPS, Docker with limited memory) would greatly benefit from reusing a central remote browser.

## Proposed Solution

1. **Configuration entry point**
- In the console (frontend UI), add a settings section for the `browser_use` tool where users can specify:
- **Remote Playwright WebSocket endpoint** (e.g., `ws://browserless:3000/playwright`)
- Alternatively (or additionally), allow setting an environment variable like `QWENPAW_PLAYWRIGHT_WS_ENDPOINT` or `PLAYWRIGHT_WS_ENDPOINT` so the remote endpoint can be injected without changing the UI.

2. **Backend behavior change**
- When the remote endpoint is configured and non-empty, the `browser_use` skill/tool should connect to that remote browser instead of launching a local browser.
- If the remote endpoint is empty/unset, fall back to the current behavior (launch a local browser, if installed).

3. **Documentation**
- Provide docs/examples for connecting to popular remote browser services like browserless, or a self-hosted Playwright server.
- Mention the environment variable / console setting in the official documentation.

## Alternatives Considered

- **Keep only local browser**: forces every deployment to install and manage a full browser. Breaks easily on newer OS versions and consumes extra memory.
- **Manually modify the code**: I could monkey-patch the Playwright connection string in the source code. However, this gets wiped on upgrades and is not maintainable across updates.
- **Use a separate proxy container**: adds another moving part and does not solve the installation issues on the host.

## Additional Context

- [browserless](https://www.browserless.io/) is a popular open-source headless browser service that exposes a Playwright-compatible WebSocket endpoint.
- Many similar projects (e.g., LangChain’s `PlaywrightURLLoader`, various RPA frameworks) already support configuring a remote browser endpoint via environment variables or constructors.

## Willing to Contribute

- [ ] I am willing to open a PR for this feature (after discussion).