Ollama Local provider crashes on streaming + tool-calling requests (non-SSE application/x-ndjson)

Version: v0.5.75 Environment: Windows 11, Ollama 0.33.3

Bug: Any request to the Ollama Local provider that combines streaming with tool definitions attached fails with:

BLOCKED 200 · non-SSE (application/x-ndjson) Error: upstream non-SSE: 200

This reproduces identically on two different local models (qwen3.6:27b-q4_k_m and gemma4:12b-it-q8_0), so it's not model-specific — it's in the connector's response handling.

Steps to reproduce:

1. Add an Ollama Local connection
2. Use it in a combo/fallback chain with a client that sends streaming requests with tools attached (in my case: Hermes agent)
3. Send a chat message that reaches this model
4. Ollama returns HTTP 200, but 9Router logs BLOCKED / non-SSE and the client never gets a response

Evidence it's isolated to streaming + tools:

• A plain non-streaming (JSON mode, no tools) test request to the same model/connection succeeds with no error
• "Test Connection" in the provider's edit modal reports "valid"
• Direct chat with the same models via ollama run works fine So Ollama, the network path, and credentials are all fine — only requests shaped like "STREAM · N TOOL" fail.

Reproduced with both models: BLOCKED 200 · ollama-local/qwen3.6:27b-q4_k_m · non-SSE (ndjson) · 97587ms BLOCKED 200 · ollama-local/gemma4:12b-it-q8_0 · non-SSE (ndjson) · 39642ms

Suspected cause: Ollama's native /api/chat endpoint streams NDJSON by design, while its OpenAI-compatible /v1/chat/completions endpoint streams SSE. It looks like the streaming client expects SSE but is hitting the native endpoint when tool-calling is involved, with no fallback parser for NDJSON.

Also noticed (may be related, happy to split into its own issue if not): the per-model "Thinking: Low/Auto" dropdown on the Ollama Local connection doesn't affect the actual reasoning-effort value sent in the request — the client kept sending THINK:8k regardless of the dropdown setting.