V2 session runner does not include MCP tools in LLM requests

Description

When using the V2 interactive session API (POST /api/session/{id}/prompt, used by the
desktop/web app), tool definitions from connected MCP servers are never included in the
outgoing request to the model. Built-in tools (read, glob, grep, bash, edit, etc.) are
included correctly. The MCP server shows as connected and its tools are discoverable, but
the model is never given them, so it can't call them.

The legacy V1 pipeline (POST /session/{id}/message) does include MCP tools correctly, so
this looks specific to the V2 session runner's tool materialization.

Reproduction

1. Configure any MCP server with one simple tool, e.g. an example_ping tool that takes no
   arguments and returns a string.
2. Confirm the server connects (GET /mcp shows "status": "connected" for it).
3. Start a session via the interactive UI (or POST /api/session then
   POST /api/session/{id}/prompt) with any agent.
4. Send a prompt that unambiguously requires the tool, e.g. "Call example_ping and show me
   the result. Call the tool, don't explain first."
5. Inspect the outgoing request to the model provider (e.g. via a local proxy in front of
   an OpenAI-compatible endpoint, or any provider request logging you have).
6. Compare: built-in tools (read, glob, etc.) are present in tools[]; example_ping
   is absent.

If there's a built-in way to inspect the materialized V2 tool set for a session without an
external proxy, it'd be useful to know for future debugging — I didn't find one and had to
tap the outgoing HTTP request directly.

Expected behavior

The V2 ToolRegistry should materialize a policy-filtered union of built-in tools, MCP
tools, plugin tools, and structured-output tools before the LLM request is built — matching
the intent already documented in the runner's own implementation checklist (see below).

Actual behavior

The V2 interactive request only ever contains the subset of tools that
packages/core/src/tool/registry.ts's ToolRegistry.materialize() currently supports:
built-in ApplicationTools entries plus generic locally-registered tools. Tools from
configured MCP servers are never added to that set, so they never reach the model.

Evidence

Reproduced with two independent, unrelated MCP servers (a stdio-local MCP server we wrote,
and an already-established, previously-working MCP server used for something unrelated to
this bug), ruling out a problem specific to one server or its tool schema:

• Server A: 4 tools expected in the outgoing request → 0/4 present.
• Server B: its tools also absent from the outgoing request.

Reproduced on two builds:

• Global release install, opencode --version → 1.18.18.
• This repo's own dev checkout, run directly via
  bun run --cwd packages/opencode --conditions=browser src/index.ts serve, at commit
  5c76f80b8898fc62c743b5768d6329f5bd8bad2e (git describe →
  github-v1.2.25-1646-g5c76f80b88, packages/opencode/package.json version 1.18.15).

Confirmed the request that actually reaches the model provider (via a transparent tap in
front of the OpenAI-compatible endpoint) contains e.g.: