fix: enable native OpenAI-style tool calling for local model providers

[octo-patch]

Fixes #857

Problem

Local model providers (Ollama, vLLM, LM Studio, liteLLM, openAICompatible) all expose an OpenAI-compatible API that supports native function/tool calling. However, models served via these providers were missing specialToolFormat: 'openai-style' in their capability definitions.

Without this flag, Void falls back to XML-based tool prompting (embedding tool definitions in the system prompt and parsing XML tags from the model's text output). This approach is unreliable for modern local models that expect to receive tools via the standard tools parameter and return tool_calls in structured JSON.

As a result, users see errors like "No Search/Replace blocks were received!" because:

1. The tools parameter is never sent in API requests to local providers
2. The model has no idea it should produce tool calls
3. The XML parser finds nothing to extract

This is consistently reported across multiple models: qwen3-coder, qwen2.5-coder, llama3.x, devstral, gemma, etc. via Ollama, vLLM, LM Studio, and liteLLM.

Solution

Add specialToolFormat: 'openai-style' to all chat/agent-capable models in:

• openSourceModelOptions_assumingOAICompat (used as fallback for unrecognized model names)
• ollamaModelOptions (Ollama-specific recognized models)

This enables:

1. The tools parameter to be sent in API requests to local providers
2. Native tool_calls responses to be parsed correctly (already implemented in the streaming handler)
3. The XML tool-prompting fallback to be skipped (it's not needed when native tool calling works)

Users who need to disable native tool calling for a specific model can override via the specialToolFormat field in their model's advanced settings JSON.

Testing

The fix is targeted at model capability definitions only and affects no runtime logic. The existing streaming handler already processes tool_calls from OpenAI-compatible responses correctly — the missing piece was sending the tools parameter.