feat(mcp): connect the user's signed-in Chrome through opencli-mcp

[Astro-Han]

Summary

Maka's built-in browser tools drive the conversation's embedded browser, which has none of the user's logins. This PR adds the other half: an MCP connection to the user's own signed-in Chrome through opencli-mcp, bundled with Maka and set up from the MCP page.

Flow. 扩展 → MCP → 推荐 → Chrome +. The click stores a stdio connection and opens the Chrome Web Store page for the extension in Chrome. The row shows 等待 Chrome (attention) and the detail keeps a 连接 Chrome action until the extension reaches the host. The page polls the host every 2 s while that is pending, so nothing needs refreshing.

Why one store click remains. Chrome installs consumer extensions only from the Web Store; silent install exists only as enterprise policy. Everything else opencli-mcp setup does now runs inside Maka:

• No Node install. Maka runs opencli-mcp on its own Electron binary with ELECTRON_RUN_AS_NODE. Two launchers under userData/opencli-mcp/ are rewritten on every start, and they are the only paths stored in mcp.json and in Chrome's host manifest. The executable path itself moves on every AppImage launch.
• Maka writes the Native Messaging manifest itself instead of calling opencli-mcp's registerHost. That function's launcher runs process.execPath without ELECTRON_RUN_AS_NODE, which under Electron would start a Maka window. The directory list, profile detection and identifiers are imported from the package, not copied. A manifest that points at another live install (for example a global opencli-mcp setup) is left alone; the stdio server reaches whichever host Chrome starts. Registration writes into Chrome's directories only when the user clicks.
• Chrome status comes from the host's /health, not from the MCP connection. Without the extension, the server still starts in its embedded runtime and lists all 16 tools. Showing that as "connected" would hide the missing step until a tab_* call fails.

The built-in browser_* tools are unchanged. The two cover different scenarios: the embedded browser is visible inside Maka and has no logins; this connection drives the user's own Chrome.

Packaging. opencli-mcp 0.0.12 is pinned exactly and has no type declarations, so the few imported modules are declared in opencli-mcp.d.ts. It ships its adapter SDK inside itself and links it with file:, which npm locks without a version. The notice generator now reads such bundled packages from their installed manifest. The SDK declares MIT but has no LICENSE file, so it gets an exact-version copyright override.

Verification

• opencli-chrome.test.ts: the POSIX launchers actually run an entry in Node mode, including a path that contains a quote (stdio and host --native, with Chrome's appended origin ignored); Windows .cmd content; manifest targeting (Chrome always, other browsers only when their profile exists, a stale manifest overwritten, another live install kept).
• module-hub-mcp-controller.test.ts: a configured Chrome server is polled until the extension connects, and polling then stops. mcp-preload-scope.test.ts covers the two new channels.
• Stories: ExtensionsMcpChrome (the click adds the server, starts connecting once, leaves 推荐) and ExtensionsMcpChromeWaiting (the row shows 等待 Chrome and counts as needing attention, not "16 个工具"). Storybook smoke passes: 409 stories, 443 theme renders.
• Packaged app: electron-builder --mac dir, then ELECTRON_RUN_AS_NODE=1 Maka.app/Contents/MacOS/Maka app.asar/node_modules/opencli-mcp/dist/src/main.js stdio initializes and runs sites_search (adapters load from the asar).
• Dev app with an isolated profile, driven over CDP: the launchers are written at startup; adding the server through window.maka.mcp.add connects with 16 tools and chromeStatus().connected === false.
• typecheck, typecheck:stories, format, lint, check:third-party-notices, audit-shipped-dependencies, windows:inventory.

Not run: Chrome → opencli-mcp-host → extension with the real Web Store extension installed; that needs a user to click Add to Chrome. Windows and Linux were not run locally. E2E is left to CI.

AI use

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: Claude Code: investigation, implementation, tests, and this description.

Checklist

• Tests cover the change and fail without it
• Lint, format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No