feat(mcp): forward MCP tools/call progress onto the existing Host progress channel

### Problem

Long-running MCP tools can take up to the 10-minute default timeout. The MCP protocol already lets a server send `notifications/progress` during `tools/call`, and Maka already has a Host/runtime channel that turns `(current, total)` into transcript `tool_progress` events (the same path Computer Use uses).

Those two ends are not connected. `McpClientManager.callTool` does not pass SDK `onprogress`, so the client never asks for a progress token. The CLI MCP capability provider (shared by TUI and the Runtime Host sidecar) never calls the Host `options.progress` hook. The result is a frozen transcript while the server may already be reporting steps.

### Desired outcome

When an MCP server sends numeric `progress`/`total` during `tools/call`, Maka shows the same step progress it already shows for other tools. Omitting a progress listener must not request a progress token. Incomplete or invalid progress must not fail the tool call.

### Alternatives or workarounds

Wait for the tool to finish with no live progress. Wiring a new Host protocol is unnecessary: `ClientCapabilityProvider.call` already accepts `progress?(current, total)` and the channel already forwards admitted progress.

This is a small implementation-level seam in `@maka/mcp` plus the existing CLI provider.