Closes the remaining ~25% of trailing-assistant 400s on llama.cpp /
vLLM / TGI that an empty-content filter alone cannot reach. The
MAX_STEPS prefill in session/prompt.ts is non-empty by design (it
delivers a user-visible "wrap up" instruction), so it survives the
empty filter and trips the same template-incompat 400.

Three coordinated changes:

1. ProviderTransform.canAcceptTrailingAssistant(model) — new helper.
   Three-layer precedence:
     (a) explicit model.capabilities.prefill wins (from models.dev or
         user config),
     (b) auto-inference: @ai-sdk/openai-compatible + reasoning:true
         → false (covers every known 2025-2026 thinking family even
         before models.dev ships explicit values),
     (c) default true (backwards compatible — Anthropic, Bedrock,
         OpenAI, Google etc. unchanged).

2. session/prompt.ts MAX_STEPS routing now consults the helper:
   role:"assistant" for prefill-capable providers, role:"user" for the
   rest. Thinking stays enabled in the request body — only the role of
   the synthetic wrap-up message changes from `assistant` to `user`,
   so the model still thinks and writes its summary normally.

3. CapabilityProbe — runtime detection for self-hosted openai-compatible
   servers. llama.cpp's `<root>/props` endpoint exposes the active
   chat template; templates that branch on `enable_thinking` are exactly
   the ones that reject prefill. The probe runs once per base URL
   (cached), fail-silent (vLLM/TGI/mistral.rs have no /props and fall
   through to the auto-inference path), short-timeout (1.5s).

User can always override per-model via opencode.json:

    {
      "provider": {
        "my-llamacpp": {
          "models": {
            "qwen3.5-coder": { "reasoning": true, "prefill": false }
          }
        }
      }
    }

Affected behaviour:
  - Anthropic, Bedrock, OpenAI, Google — unchanged (prefill stays
    available).
  - Thinking-on local models (Qwen3, DeepSeek-R1, GLM-thinking,
    Kimi-K2-Thinking, MiniMax-M2): MAX_STEPS arrives as a user message.
    Same instruction, same wrap-up behaviour, no template rejection.

Tests:
  - transform.test.ts: 8-case canAcceptTrailingAssistant matrix
    (explicit-overrides-everything, auto-inference for openai-compatible
    + reasoning class, unchanged defaults for Anthropic/OpenAI/Google/
    Bedrock representatives).
  - capability-probe.test.ts: 11 cases for the runtime probe
    (enable_thinking detection, /v1-suffix normalisation, 404 fallback,
    network-error fallback, empty baseURL, per-URL cache).

Real-world benchmark against an echomodus-sized Spring Boot project
on llama.cpp + Qwen3.5-9B with --reasoning on:
  - Without this PR: 2.0 prefill-400s per run (3/3 runs).
  - With this PR + reasoning:true in user config: 0 errors (3/3).
  - With this PR + auto-probe (no user config): 0 errors (3/3).

Common misunderstanding: prefill:false does NOT disable thinking.
Thinking stays on for the whole request — only the role of the synthetic
MAX_STEPS message changes from `assistant` to `user`. The model then
thinks (with thinking enabled) and writes its wrap-up normally.

Builds on the Model.prefill capability introduced in the previous
commit. Sister-PR-1 (filter empty assistant content for
@ai-sdk/openai-compatible) handles the orthogonal empty-trailing case;
this PR handles the non-empty trailing case.