add operator max steps to request

[dragon18456]

Adds max steps to operator in the request so you can raise or lower it.

[xTRam1]

Because this is a new public SDK parameter, please document the semantics at the API boundary rather than only plumbing it through. The name says “operator steps”, but callers need to know the production contract: this should cap cumulative operator/browser-action steps for the run/session, valid values are 1..100, and exceeding it raises NaradaOperatorMaxStepsExceededError with max_operator_steps populated when the backend includes it.

I would add a short docstring/API-docs entry along these lines:

max_operator_steps: Optional cap on the number of cumulative Operator
    browser-action steps the run may take. Must be between 1 and 100.
    When the cap is reached, Agent.run raises
    NaradaOperatorMaxStepsExceededError.

This matters because otherwise external users may read this as a timeout, a token/LLM-iteration cap, or a per-request retry limit. The SDK should describe the same cumulative behavior that the caddie implementation enforces, especially since this is now part of the public surface of Agent.run().

[xTRam1]

Same public API concern for the Pyodide package: this parameter should be documented wherever the browser SDK surface is documented, not only forwarded. Agent Studio / Pyodide users are often less close to the backend implementation, so the distinction between “operator browser-action steps” and “LLM iterations” is especially important here.

Please keep the CPython and Pyodide docs/signatures aligned and describe the same behavior in both places:

max_operator_steps: Optional cap on cumulative Operator browser-action
    steps for this run/session. Must be 1..100. Raises
    NaradaOperatorMaxStepsExceededError when reached.

That also gives us a clean contract to test against across the three repos: SDK sends operatorMaxIterations, frontend preserves it through remote dispatch, and caddie enforces it cumulatively in the operator persisted runtime.