feat(mcp): forward progress_callback to ClientSession.call_tool

[davidbolvansky-invicti]

Summary

Forward the progress_callback parameter from MCPClient.call_tool_sync / call_tool_async through to the underlying ClientSession.call_tool().

When a progress_callback is provided, the MCP SDK automatically includes a progressToken in the request metadata, enabling MCP servers to send notifications/progress via ctx.report_progress(). Without this passthrough, ctx.report_progress() silently no-ops because no token is present.

This is essential for long-running MCP tools (crawls, orchestration waits) where:

• Progress notifications keep the HTTP/SSE connection alive (resetting read timeouts)
• Callers get real-time visibility into operation status

Changes

• Added progress_callback: ProgressFnT | None = None parameter to _create_call_tool_coroutine, call_tool_sync, and call_tool_async
• Forward progress_callback to ClientSession.call_tool() in the direct (non-task) execution path
• Added tests for sync and async progress callback forwarding
• Updated existing test assertions to match the new keyword argument

Pattern

This follows the exact same pattern as the meta parameter added in #1918 — one parameter passthrough per method, fully backwards-compatible.

[strentom]

Hello @davidbolvansky-invicti , you mentioned this closes my issue #1812 . But does it? Your PR mentions

direct (non-task) execution

but #1812 is about tasks, not just regular Tool Call progress updates.

Can you please give a code example to use this with a Task and polling? I think this line should call the callback instead of no-op, no?

[davidbolvansky-invicti]

Yes, you are right, this will not fix that MR. I had it in mind as something related, but my goal is to fix call tool progress reporting as I would like to use as downstream consumer of this Strands SDK.