fix(runtime): replay provider-facing MCP arguments

[M4n5ter]

English

Summary

• persist provider-facing MCP arguments instead of the proxy transport envelope
• keep rejected Client Capability calls replayable with the schema the model originally used
• cover the Ask-boundary rejection and subsequent RuntimeEvent replay with a real SQLite regression test

Root cause

buildMcpTools projected every MCP call into { serverId, toolName, arguments } before persistence. RuntimeEvent history later replayed that internal transport shape as the model's own tool input. A model following its history nested the envelope again, so the actual MCP schema rejected the call.

The MCP proxy closure already owns the server and tool identity. Persisting that identity inside provider-facing arguments was redundant and made the model history invalid.

Validation

• @maka/runtime full test suite: 3,179 passed, 0 failed, 9 skipped
• Runtime Host execution-model composition: 19 passed, 0 failed
• @maka/runtime typecheck
• Biome check

中文

概要

• 持久化 provider-facing MCP 参数，不再持久化 proxy 内部传输 envelope
• 确保被执行边界拒绝的 Client Capability 调用仍以模型最初使用的合法 schema 回放
• 使用真实 SQLite 回归测试覆盖 Ask 边界拒绝和后续 RuntimeEvent replay

根因

buildMcpTools 在持久化前将每个 MCP 调用投影为 { serverId, toolName, arguments }。RuntimeEvent 历史随后把这个内部传输结构作为模型自己的工具参数回放。模型模仿历史时再次嵌套 envelope，最终被真实 MCP schema 拒绝。

MCP proxy 的闭包已经持有 server 和 tool 身份，因此把这部分身份写入 provider-facing 参数既重复，又会破坏模型历史。

验证

• @maka/runtime 全量测试：3,179 passed，0 failed，9 skipped
• Runtime Host execution-model composition：19 passed，0 failed
• @maka/runtime typecheck
• Biome check