fix: propagate container.id across toolRunner iterations

[Yanhu007]

Summary

Fixes #964

When using code_execution_20260120 with client-side betaTools, the first API response returns a container object with an id. However, BetaToolRunner's async iterator loop never forwards this container.id back into params.container for subsequent requests. This causes the second iteration to fail because the API doesn't know which container to reuse.

Root Cause

In the main loop ([Symbol.asyncIterator]), after receiving a response:

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

Only role and content are extracted — container from the response is discarded.

Fix

After appending the message to history, check if the response includes a container.id and propagate it to params.container:

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

if (message.container?.id && this.#state.params.container !== message.container.id) {
  this.#state.params.container = message.container.id;
}

Why this also fixes Bug 2 (infinite loop)

The workaround of using setMessagesParams to manually set container.id caused #mutated = true, which skipped the messages.push() step. This meant the assistant's response was never added to history, causing generateToolResponse to re-process old messages in an infinite loop.

With automatic container propagation, users no longer need setMessagesParams for this purpose, avoiding the infinite loop entirely.