[Platform] Boolean options not supported in AbstractModelCatalog::parseModelName()

[sonnymilton]

Currently, AbstractModelCatalog::parseModelName() relies on AbstractModelCatalog::convertNumericStrings() which only converts numeric strings to integers/floats.

However, boolean-like query parameters (e.g. ?think=false) are always parsed as strings. This makes it harder to pass boolean options to models, since they need to be manually casted.

Example:

$catalog = new \Symfony\AI\Platform\Bridge\Ollama\ModelCatalog();
$model = $catalog->getModel('qwen3:0.6b?think=false');
$client = new \Symfony\AI\Platform\Bridge\Ollama\OllamaClient(
    Symfony\Component\HttpClient\HttpClient::create(),
    $_ENV['OLLAMA_HOST']
);
$options = $model->getOptions(); // ['think' => 'false']

// will throw an exception because ollama responds with 400 Bad request
// {"error":"invalid think value: \"false\" (must be \"high\", \"medium\", \"low\", true, or false)"}
$client->request(
    $model,
    [new \Symfony\AI\Platform\Message\UserMessage(
        new \Symfony\AI\Platform\Message\Content\Text('Hello world'),
    )],
    $model->getOptions()
);

Here think=false is passed as a string ('false'), but Ollama server expects a real boolean false.

Expected behavior:

Boolean-like strings should be automatically converted to booleans.

Proposed solution:

Introduce a more general converter, e.g. convertScalarStrings(), that handles both numeric and boolean strings.

[sonnymilton]

I’d like to raise one point regarding backward compatibility.

If we start automatically converting "true"/"false" strings to booleans, there’s a (theoretical) risk that some provider might intentionally require the literal string "false" or "true" as a valid option value. In such cases, implicit conversion could change the semantics of the request.

Do we want to support any options for escaping these values?

[OskarStark]

No. Not for now, lets tackle this when it pops up