[Feature] No way to control reasoning/thinking in the standalone LLM path (truncated responses become empty extractions)

Is this feature related to a problem? | 该功能需求是否与某个问题相关？

Yes — a reasoning model can silently destroy an extraction batch.

In our standalone deployment the L1 layer runs with maxTokens: 4096. When the active model emits reasoning before the answer, the reasoning consumes the output budget, the visible content is cut off mid-JSON (finishReason=length, e.g. a 121-char fragment) and the extraction yields nothing. On one day this produced 8 such batches for L1; combined with a provider quota outage they caused the data loss described in #1395.

There is currently no switch for this anywhere in the standalone path:

• StandaloneLLMConfig (src/adapters/standalone/llm-runner.ts) has no thinking/reasoning field;
• llm-runner.ts never touches the request body for it.

We also verified that routing it through the AI SDK is not sufficient on the compatible path: a fetch-layer probe showed the outgoing body had thinking: undefined when the field was passed via providerOptions.openai.thinking, i.e. it never reached the provider — so the value has to be injected where the request body is built.

Describe the solution you'd like | 描述你期望的解决方案

A per-provider disableThinking (and per-layer, see #1396) honoured by the standalone runner, implemented at the request-body/fetch layer instead of relying on providerOptions:

llm:
  providers:
    - name: some-gateway
      extra:
        disableThinking: true

We already run exactly that as a local patch (L1 = thinking off + small budget; L2/L3 = thinking on + large budget) and can send it as a PR.

Describe alternatives you've considered | 描述你考虑过的其他方案

• Only raising maxTokens: works around truncation but wastes budget and does not fix the strict-JSON case;
• Telling users to select non-reasoning models: loses the quality benefit on L2/L3 — which is exactly why the per-layer split in #1396 matters;
• Documenting it as a known limitation: leaves a silent failure mode in place.

Additional context | 补充说明

Environment: standalone · Node 22 · OpenAI-compatible providers (multiple vendors, incl. monthly-plan gateways).

Relation to the other reports: #1395 makes a failed batch deferred instead of lost, and #1396 lets each layer pick its own model/budget — this report is the missing knob so L1 can reliably ask for strict JSON while L2/L3 keep reasoning enabled.

（中文摘要）standalone 链路完全没有思考/推理开关：L1 用 4096 预算时，推理模型会把预算烧在思考上、可见内容被截断成半截 JSON（finishReason=length），当日实测 8 个批次因此零产出（叠加限额即 #1395 的丢数据）。且经 fetch 层探针实证，走 AI SDK 的 providerOptions.openai.thinking 在兼容路径上根本没有发到上游（body 里 thinking=undefined）——必须在构造请求体处注入。建议加 per-provider（并配合 #1396 做到 per-layer）的 disableThinking；本机已按此实现并可用，方向认可即可提 PR。