feat(desktop): MCP servers defined in .mcp.json are not visible to agent sessions

## Problem

When an MCP server is added to `.mcp.json` in the agent's working directory and Buzz Desktop is restarted, the server's tools are **never surfaced to the agent session**. The agent reports only its built-in tools (e.g. `buzz-dev-mcp`). The MCP server is completely invisible.

### Reproduction steps

1. Install an MCP server locally, e.g. `@playwright/mcp` (`npm install @playwright/mcp`).
2. Add an entry to `.mcp.json` in the agent's working directory:
```json
{
mcpServers: {
playwright: {
command: node,
args: [
node_modules/@playwright/mcp/cli.js,
--user-data-dir, C:\Users\0\.buzz\chrome-matthew-don,
--executable-path, C:\Users\0\.cloakbrowser\chromium-146.0.7680.177.5\chrome.exe
]
}
}
}
```
3. Restart Buzz Desktop.
4. Trigger an agent session and query which tools are available.

**Expected:** The agent session lists tools provided by the `playwright` MCP server (e.g. `browser_navigate`, `browser_snapshot`, etc.).

**Actual:** Agent session reports zero playwright tools. Only built-in tools are present.

### Additional confirmation

The MCP server binary runs without errors when launched manually:
```
cd C:\Users\0\.buzz
node node_modules\@playwright\mcp\cli.js --user-data-dir=... --executable-path=...
```
No crash, no error output. The server itself is healthy — Buzz Desktop simply never wires it through.

Also confirmed: no per-agent `mcp_servers` field exists in `managed-agents.json` (`C:\Users\0\AppData\Roaming\xyz.block.buzz.app\agents\managed-agents.json`). There is no second config to update.

## Root cause (hypothesis)

Buzz Desktop spawns MCP servers at startup, but there is no mechanism that injects the discovered tools from those servers into an agent's tool list for the session. The connection between "server is running" and "agent can call its tools" is the missing link. PR #4588 adds the Project-owned connection model that appears to be the infra foundation for this.

## Impact

Without persistent MCP tools, agents are forced into an anti-pattern workaround: chain all browser automation steps into a single shell call because the browser is a child process of the shell and is killed when the shell exits:

```bash
cd /c/Users/0/.buzz && npx @playwright/cli open --headed & sleep 4 && npx @playwright/cli --s=default goto 'https://x.com/...' && npx @playwright/cli --s=default snapshot
```

This means:
- No multi-step interactive sessions — the entire sequence must be planned upfront
- No ability to react to page state between steps
- No persistent authenticated browser context across tool calls

This is a significant capability gap for any agent doing web automation (outreach, scraping, form filling, etc.).

## Related

- PR #4588 — adds Project-owned MCP connection model (infra foundation)
- Issue #4515 — missing docs on how Desktop picks up `.mcp.json`

## Suggested resolution

1. After PR #4588 lands, implement agent bindings so a Project-owned MCP connection's tools are injected into agent sessions bound to that project.
2. Add a UI indicator in Desktop showing which MCP servers are active and their tools are available to the current agent session — right now there is zero feedback on whether a server loaded or failed silently.
3. Document the end-to-end flow: add `.mcp.json` entry → configure Project connection → bind agent → confirm tools visible in session.