Respect explicit reasoning config during GGUF thinking probe

[leinasi2014]

Summary

• respect explicit reasoning.disable and disable_reasoning_tag_prefill values during GGUF thinking probing
• still infer missing reasoning defaults when only part of the reasoning config is explicit
• add targeted tests for both config inference and runtime probe gating

Problem

reasoning.disable is an official LocalAI model config, but on the GGUF + tokenizer-template path the backend thinking probe could overwrite explicit YAML values after model load.

There was also a related runtime gap: thinking probing only ran when both reasoning fields were nil, so partial explicit config could not preserve one field while inferring the other.

Fixes #9462.

Related context

This work is in the same broader reasoning/thinking area as:

• Handling of models pulled from HF does not properly handle thinking #7944
• Output from reasoning models not parsed correctly #8036
• fix(realtime): Better support for thinking models and setting model parameters #8595

Those items are related background, but this PR specifically fixes reasoning config precedence and probe gating.

Changes

• in core/config/gguf.go, only fill inferred reasoning values when the field is still unset
• in core/backend/llm.go, probe when tokenizer templates are enabled and either reasoning field is unset
• add core/config/gguf_reasoning_test.go
• add core/backend/llm_probe_test.go

Validation

• go test ./core/config ./core/backend ./pkg/reasoning
• verified in a live LocalAI distributed deployment that runtime config-json now preserves explicit reasoning config
• reran minimal diagnostics and confirmed metadata.enable_thinking=false now produces the expected low-latency behavior at runtime

[leinasi2014]

Thanks. I dug into the three failing checks and they do not appear to come from this reasoning-config fix.

1. Yamllint

   • This is failing in gallery/index.yaml because of duplicate sha256 keys.
   • Current offending lines reported by CI are around 15267, 15303, and 15347.

2. ests-linux

• The failing spec is core/http/app_test.go:848 (installs and is capable to run tts).
• The visible failure is model "voice-en-us-kathleen-low" not found, but the same job log shows the install/apply path already failing because gallery/index.yaml cannot be unmarshaled due to those duplicate sha256 keys.
• In other words, the TTS model never gets installed, and the later /tts request returns 404 as a downstream symptom.

3. ests-e2e-backend

• This one is a stale distributed E2E compile issue in ests/e2e/distributed/node_lifecycle_test.go.
• That test still calls InstallBackend(...) with the old argument list, while the current interface now expects 7 arguments.

The files touched by this PR are limited to:

• core/config/gguf.go
• core/backend/llm.go
• the two new reasoning-related tests

So from what I can see, these CI failures are pre-existing / orthogonal to the change here, not regressions introduced by this PR.