Fix Ollama `enable_thinking` setting being silently dropped on the live class
construction path. Reasoning models (deepseek-r1, qwen2.5) now correctly
receive `reasoning=True/False` per the user's `llm.ollama.enable_thinking`
setting. Also apply the 80%-of-context-window `max_tokens` cap on every
provider's `create_llm` (was previously only applied in dead procedural
code that never ran in production) and unify the optional-API-key
placeholder string across all providers (`"not-required"`). Note: users
who set `llm.context_window_unrestricted = false` together with a small
`llm.context_window_size` will now have `max_tokens` capped at 80% of
that window for OpenAI/Anthropic too — previously the cap only applied
to Ollama. For LM Studio and llama.cpp the cap is always active, keyed
to `llm.local_context_window_size` (default 20480 → effective cap 16384
with the default `llm.max_tokens` of 30000). `llm.supports_max_tokens =
false` is now honored on the live path (previously the kwarg was sent
regardless), and whitespace-only API keys for required-key providers now
raise a clear error at construction instead of being sent to the API.

Ollama's `num_ctx` now resolves through the same shared helper as the
context-overflow bookkeeping, so the reported `context_limit` always
matches the window the model actually runs with (previously an absent or
null `llm.local_context_window_size` produced `num_ctx` 4096/server-default
while overflow detection assumed 8192). The ineffective `max_tokens`
kwarg is no longer passed to `ChatOllama` (it was silently ignored;
`num_ctx` is the effective control). A keyless `openai_endpoint`
configuration is now permitted — it previously raised "API key not
configured" at construction, blocking keyless local servers (vLLM,
text-generation-webui); a warning is logged so endpoints that do
require a key remain diagnosable.

Also fix `llama.cpp` provider availability check: instances behind an
authentication proxy now correctly report as available when
`llm.llamacpp.api_key` is configured. Previously the probe was sent
without credentials and was always rejected, so users with auth-proxied
llama-server saw the provider as unavailable regardless of server state.
