Ollama providers (native `ollama` and "Ollama Compatible" custom provider) never call /api/chat, so think/hybrid-reasoning control is unreachable

---

**Describe the bug**

Both of Goose's Ollama-talking code paths — the native `ollama` provider
(`crates/goose-providers/src/ollama.rs`) and the generic "Ollama Compatible"
custom/OpenAI-compatible provider (`openai_compatible.rs`) — build their
request and POST it to `v1/chat/completions` (Ollama's OpenAI-compatibility
endpoint). Neither ever calls `/api/chat` or `/api/generate`, Ollama's
native endpoints.

This means Ollama's `think` field — used to disable/enable "thinking" on
hybrid-reasoning models such as Qwen3 or DeepSeek-R1 — can never be set by
Goose, in either provider mode. There's also no config.yaml key, env var,
or UI setting that maps to it today, and even Goose's existing
`ModelConfig.request_params` passthrough (which does get merged into the
outgoing JSON body, see `crates/goose-provider-types/src/formats/openai.rs:1798`)
can't help, since it still ends up in a `v1/chat/completions` request that
silently drops the field regardless.

Practical effect: anyone running a hybrid-reasoning model locally via
Ollama through Goose gets full "thinking" on every single turn, with no way
to disable it — slower and noisier than necessary for straightforward
tool-calling tasks.

---

**To Reproduce**

1. Configure Goose with either the native `ollama` provider or a custom
"Ollama Compatible" provider pointed at a local Ollama instance.
2. Select `qwen3:8b` (or any other hybrid-reasoning model Ollama supports).
3. Send any prompt and inspect the request Goose sends (or Ollama's own
request logs) — it goes to `v1/chat/completions`.
4. Try to disable thinking via any available Goose setting (system prompt,
`.goosehints`, config.yaml, env var) — none of them reach the model's
`think` field, and the response always contains a full `...`
block regardless.

Confirmed directly against a local Ollama server (v0.33.3), independent of
Goose, to isolate where the field gets dropped:

- `POST /v1/chat/completions` with `"think": false` in the body → response
is identical (length, latency, and reasoning content) to the same request
*without* the field. It's silently ignored.
- `POST /api/chat` with `"think": false` → thinking is genuinely disabled:
2.6s response, zero reasoning content — versus ~36s with a full
`` block on an identical prompt when `think` is omitted.

Also tried working around it at the model level — a custom Ollama Modelfile
with a hand-edited chat template that unconditionally appends `/no_think`
to the last user turn (so no API field is needed at all). Queried this
custom model through `v1/chat/completions` exactly as Goose would — it
still produced a full `` block. So a text-level `/no_think` workaround
isn't reliable either, at least not for `qwen3:8b` (Q4_K_M).

---

**Expected behavior**

Goose's Ollama provider(s) should offer a way to control the `think` field
— e.g. by talking to Ollama's native `/api/chat` endpoint (instead of, or
in addition to, `v1/chat/completions`), with `think` exposed as a
configurable option (env var, config.yaml key, or UI toggle).

---

**Screenshots**

N/A — this is a backend request-routing issue, reproduced via direct API
comparison rather than a UI glitch. Happy to attach a diagnostics zip if
useful, or the raw request/response JSON from the comparisons above.

---

**Please provide the following information**
- **OS & Arch:** Arch Linux, x86_64
- **Interface:** CLI (`goose run`) — same provider code path used by Desktop
- **Version:** 1.49.0 (AUR `goose-desktop-bin`)
- **Extensions enabled:** developer
- **Provider & Model:** Ollama (both native `ollama` provider and a custom
"Ollama Compatible" provider tested) – `qwen3:8b` (Q4_K_M). Ollama server
version 0.33.3.

---

**Additional context**

Suggested fix: route the Ollama provider(s) through `/api/chat` (or
`/api/generate`) instead of `v1/chat/completions`, and expose `think` as a
configurable option that maps to it. This would need the same kind of
request/response translation Goose's OpenAI-format code already does
conceptually, just targeting Ollama's native schema instead of (or in
addition to) the OpenAI-compatible one.