fix(tool_runner): propagate container_id for programmatic tool calling

[stephaniepang97]

Problem

When using programmatic tool calling (PTC) with tool_runner, the API returns a container_id in the response that must be passed in subsequent requests. Without this, the API returns:

container_id is required when there are pending tool uses generated by code execution with tools.

Solution

Update both sync and async tool runners to extract message.container.id from responses and set it in self._params["container"] for subsequent API calls.

Changes

• BaseSyncToolRunner.__run__(): Added container propagation after getting message
• BaseAsyncToolRunner.__run__(): Added container propagation after getting message (async version)

Testing

This enables using tool_runner with programmatic tool calling where client-side tools are called from within code execution. The container lifecycle is now properly managed across requests.

Example

runner = client.beta.messages.tool_runner(
    model="claude-sonnet-4-5",
    tools=[
        {"type": "code_execution_20250825", "name": "code_execution"},
        {
            "name": "my_tool",
            "description": "...",
            "input_schema": {...},
            "allowed_callers": ["code_execution_20250825"]
        }
    ],
    messages=[...],
    betas=["advanced-tool-use-2025-11-20"],
)

for message in runner:
    # Now works! Container ID is automatically propagated between requests
    print(message)

[dtmeadows]

This looks good to me and the reasoning makes sense. @karpetrosyan can I leave the final review to you? If it's helpful here's the specific place in the docs about having to pass this: https://platform.claude.com/docs/en/agents-and-tools/tool-use/programmatic-tool-calling#step-3-provide-tool-result

[karpetrosyan]

LGTM!
nit: I think it's better to commit as a feature, like feat(tool runner): add support for programmatic tool calling

[karpetrosyan]

@stephaniepang97 Can we, instead of using the container.id from the last API response, rely on the last assistant message (runner._get_last_assistant_message_content)? The user might change the state during the loop (e.g., in a for block via set_messages_params), so we should take the ID from the last message in the current state, not from the last API response

[karpetrosyan]

Can we add a simple test for this case to make sure we’re sending container.id back? We can use a snapshot with a real example and record it, like we do in the other tests.