fix(toolRunner): propagate container.id across iterations

[claygeo]

Summary

Closes #964 (Bug 1)

When using toolRunner with code_execution_20260120 and client-side tools (betaTool), the container.id from the API response was not forwarded to the next iteration, causing:

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

Root cause

BetaToolRunner.ts:209 extracted only { role, content } from the response message, discarding the container field. The next API call was made without container.id, even though the server requires it for container reuse.

Fix

After extracting the response message, propagate container.id to the next iteration's params:

const message = await this.#message;
const { role, content } = message;
this.#state.params.messages.push({ role, content });

// Propagate container.id for code_execution tool reuse
if (message.container?.id) {
  this.#state.params.container = message.container.id;
}

Uses the string form of the container param (one of the accepted types: BetaContainerParams | string | null).

Scope

This addresses Bug 1 from the issue (missing container.id propagation). Bug 2 (setMessagesParams infinite loop) has a different root cause and should be tracked separately.

Test plan

• With container in response → container.id is set on params for next iteration
• Without container in response → params unchanged (existing behavior preserved)
• Matches how the runner already stitches tool_use/tool_result message pairs between iterations