fix: propagate container.id across toolRunner iterations

[Sarmkadan]

Summary

Fixes #964 — toolRunner does not propagate container.id across iterations, causing a hard error when using code_execution with client-side betaTools.

Root cause

When the API returns a response with a container object (created by code_execution), the container.id must be included in subsequent requests so the API can reuse the same container. Neither BetaToolRunner nor the legacy ToolRunner extracted this value from the response, so the next iteration sent a request without container, triggering:

{"type":"invalid_request_error","message":"container_id is required when there are pending tool uses generated by code execution with tools."}

The only workaround (setMessagesParams) also didn't work correctly — setting container via the mutator triggered the #mutated flag, which prevented the assistant message from being pushed to the conversation history, causing an infinite loop (Bug 2 in the issue).

Fix

After awaiting each response, extract container.id and set it on this.#state.params.container before the #mutated check. This ensures:

1. The container is propagated regardless of whether the user called setMessagesParams
2. Users no longer need the broken setMessagesParams workaround
3. The fix is minimal — 4 lines of logic in each runner

Applied to both BetaToolRunner and the legacy ToolRunner.

Test plan

• forwards container.id from response to next request — non-streaming mode, verifies second request body contains container
• forwards container.id in streaming mode — same verification via SSE streaming
• All 30 existing ToolRunner tests pass