#20207: fix(browser): use profile driver instead of hardcoded name

## Summary Fixes a browser tool regression where extension-specific behavior was keyed off profile **name** (`"chrome"`) instead of profile **driver** (`"extension"`). This caused false positives/negatives: - non-extension profiles named `chrome` were treated like Browser Relay extension profiles - extension profiles with custom names were not treated as extension profiles ## What changed ### 1) Browser tool now uses driver-based checks In `src/agents/tools/browser-tool.ts`: - Added `resolveConfiguredProfileDriver(profileName)` - Replaced hardcoded checks: - `profile === "chrome"` → `profileDriver === "extension"` for target defaulting - `profile === "chrome"` → `profileDriver === "extension"` for tab-not-found relay guidance - Added safe fallback (`try/catch`) in profile driver resolution to avoid throwing from config reads ### 2) Expose profile driver in browser API/status payloads - `src/browser/client.ts` - `BrowserStatus.driver?: "openclaw" | "extension"` - `ProfileStatus.driver: "openclaw" | "extension"` - `src/browser/server-context.types.ts` - Added `driver` to `ProfileStatus` - `src/browser/server-context.ts` - `listProfiles()` now includes `driver` - `src/browser/routes/basic.ts` - `/` status response now includes `driver` ### 3) Regression tests - `src/agents/tools/browser-tool.e2e.test.ts` - extension custom profile defaults to host - non-extension profile named `chrome` keeps sandbox path - extension custom profile gets relay-specific tab guidance - non-extension `chrome` profile does not get relay guidance - `src/browser/server.post-tabs-open-profile-unknown-returns-404.test.ts` - verifies `driver` is present in `/` status and `/profiles` responses ## Why this fix The server-side browser layer already uses `profile.driver` semantics. This PR aligns the agent browser tool with that same contract, removing brittle name-coupling and fixing issue behavior reported in #11926. Fixes #11926 <!-- greptile_comment --> <h3>Greptile Summary</h3> This PR fixes a browser tool regression where extension-specific behavior was keyed off profile **name** (`"chrome"`) instead of profile **driver** (`"extension"`). A new `resolveConfiguredProfileDriver()` helper reads the driver from config and the two checks in `browser-tool.ts` now use `profileDriver === "extension"` instead of `profile === "chrome"`. The server-side API (`/` status and `/profiles`) now also exposes the `driver` field, with corresponding type updates in both client and server types. - The core fix correctly decouples extension detection from profile naming, aligning the agent tool with the server-side `profile.driver` contract - `resolveConfiguredProfileDriver` is safely wrapped in try/catch with proper input trimming - `driver` field added to `BrowserStatus` (optional for backward compat), `ProfileStatus` (required), and both API responses - Four targeted regression tests in `browser-tool.e2e.test.ts` cover the key scenarios (custom extension profile → host, non-extension "chrome" → sandbox, extension guidance, non-extension no guidance) - One remaining issue: an error message on line 837 of `browser-tool.ts` still hardcodes `profile="chrome"` instead of using the actual profile name variable — this is the same name-coupling bug this PR aims to fix <h3>Confidence Score: 4/5</h3> - This PR is safe to merge with one minor hardcoded string to fix in an error message - The core logic change is correct and well-tested. Types are consistent across client/server boundaries. The only issue is a leftover hardcoded `profile="chrome"` in an error message that contradicts the PR's goal of removing name-coupling. This won't cause runtime failures but will show incorrect guidance to users with custom-named extension profiles. - `src/agents/tools/browser-tool.ts` — hardcoded `profile="chrome"` in error message at line 837 _{Last reviewed commit: d4fc659} <!-- greptile_other_comments_section --> <!-- /greptile_comment -->