fix(tools): accept integer OR string for browser_task max_steps

[escapeboy]

Fixes Sentry #1084; #937 was the downstream failure of the same run.

Problem

Groq Error [400]: invalid_request_error - tool call validation failed:
parameters for tool browser_task did not match schema:
errors: [`/max_steps`: expected number, but got string]

The model emitted "10" instead of 10. Providers validate the model's tool call against our advertised schema, server-side — the call is rejected before it ever reaches the app, so there is nothing for us to coerce at runtime. Our schema was not wrong; it was simply stricter than what the model reliably produces.

Change

Widen the advertised type to ["integer","string"] on all three browser_task declarations (the inert/disabled one, the sidecar one, and the browser-use Cloud one — the inert one still advertises its schema to the LLM, so it needs it too), and normalise to int at the seam via normaliseMaxSteps().

RawSchema is used rather than AnyOfSchema so this stays a plain JSON Schema type union instead of anyOf, which strict function-calling modes tend to reject.

Tests

• schema assertion across both transport kinds (browser + browser_use_cloud)
• behavioural: max_steps: '7' reaches the sidecar as integer 7
• 231 tests pass across Unit/Domain/Tool + Feature/Domain/Tool; pint + phpstan clean on the touched files

Note on scope

This is a tolerance change, not a claim that the model bug is ours. It stops one malformed generation from failing an entire agent run.