#17645: fix: browser control service actually start HTTP server in Docker

## Summary The browser control service was not binding to port 18791 in Docker deployments because the gateway was importing from `control-service.js` by default, which exports `startBrowserControlServiceFromConfig` that does NOT start an HTTP server - it just logs "ready" and returns. Changed the default import to `server.js`, which exports `startBrowserControlServerFromConfig` that actually binds to the port. ## Changes - Changed default import in `src/gateway/server-browser.ts` from `"../browser/control-service.js"` to `"../browser/server.js"` ## Testing - Build completed successfully - The fix restores the behavior that was accidentally changed in commit e7fdccce3 Fixes openclaw/openclaw#17584 <!-- greptile_comment --> <h3>Greptile Summary</h3> Fixed a critical bug where the browser control service wasn't actually starting an HTTP server in Docker deployments. The gateway was importing from `control-service.js` which only initializes state and logs "ready" without binding to port 18791. Changed the default import to `server.js` which properly creates an Express server and binds to the port. The code already has fallback logic to handle both function names (`startBrowserControlServiceFromConfig` and `startBrowserControlServerFromConfig`), so this change is backward compatible with custom module overrides. <h3>Confidence Score: 5/5</h3> - This PR is safe to merge with no risk - This is a straightforward one-line fix that correctly addresses the root cause. The code already has proper fallback logic to handle both the old and new function names, ensuring backward compatibility. The change restores the intended behavior of actually starting an HTTP server on port 18791 instead of just initializing state. No tests need updating since the test harness already imports from `server.js` directly. - No files require special attention _{Last reviewed commit: f6db123} <!-- greptile_other_comments_section --> <!-- /greptile_comment -->