Use the original request model for tool-loop follow-up requests

[sulimanbenhalim]

Fixes #680

When generateText runs a multi-step tool loop, six gateways build the follow-up request after tool results using the model from the API response ($data['model']) instead of the original model the caller requested. When a provider resolves the requested alias to a different id in its response, the next tool-call request goes out with that resolved id and fails with model_not_found.

The original model is dropped at the parse boundary: generateText builds the first request with the caller's $model but never passes it into parseTextResponse, so the parser falls back to $data['model'] and reuses it for the follow-up request body.

Affected: Xai, Mistral, DeepSeek, Groq, Ollama, OpenRouter. OpenAI and Anthropic already carry the original request body through the loop, and Gemini already threads the original model, so they are not affected. The streaming path was already correct everywhere (it threads the original model from streamText).

The fix

Thread the caller's model through as an optional $requestModel from generateText → parseTextResponse → processResponse → continueWithToolResults, and use it for the follow-up request body ($requestModel ?? $model). Meta/Step reporting is intentionally left on the response model, so $response->meta->model still reflects the model the provider actually used. The parameter is optional and falls back to the response model, so nothing else changes.

Tests

The reporter wasn't able to share a repro, so the added tests are the repro. Each affected gateway's ToolCallLoopTest gets a regression test that fakes a tool-call response whose model differs from the requested alias, then asserts the follow-up request uses the original alias (and that meta->model still reports the response model). Every one of them fails on 0.x today and passes with this change. Full suite, Pint, and PHPStan all pass.