cursor: every native Run replays full conversation state and re-advertises all MCP schemas (perf)

## Observation

Every native Cursor `agent.v1.AgentService/Run` rebuilds and re-sends the full conversation state and re-advertises every non-native tool as an MCP schema. Measured on current main with `buildCursorHistoryForTest` / `buildMcpToolDefinitions`:

| turns | replayed state (JSON-serialized) |
|---|---|
| 10 | 51.1 KB |
| 50 | 255.5 KB |
| 200 | 1,022.4 KB |

Plus ~71 KB (~3.6 KB/tool) of MCP tool definitions for a 20-tool set, re-sent on every Run. By comparison, an xAI/OpenAI completions hop sends messages + tool JSON once per request without checkpoint/kv blob round-trips.

## Constraint

The full rebuild is protocol-required today: Cursor checkpoints replace historical user entries with empty placeholders (cursor-agent bundle ~line 3154), so a client that does not rebuild `rootPromptMessagesJson` loses history. This is a performance concern, not a correctness bug.

## Possible directions (need before/after evidence per the report thread)

- Measure serialized MCP bytes, request latency, and tool availability before/after any schema pruning so pruning cannot silently remove a needed capability.
- Investigate blob-store reuse across Runs on the same conversationId (kv blobs are content-addressed; the server may already dedupe - verify with wire captures).
- Consider trimming tool descriptions/schemas advertised to Cursor specifically, behind measurement.

Start with the native agent.v1.AgentService/Run path and the buildCursorHistoryForTest and buildMcpToolDefinitions measurements. Inspect rootPromptMessagesJson and verify blob-store reuse with wire captures before changing schema or history handling. Done requires before/after serialized-byte and latency evidence while preserving conversation history and every required tool capability.

Written by the indexing model from the issue text.