fix(provider): apply MergeSystemMessages for vLLM provider

[tmchow]

Summary

Apply MergeSystemMessages to the vLLM built-in provider in addition to NVIDIA. vLLM rejects requests where the system message is not first, which is exactly what this transformer was built to handle.

Why this matters

Issue #3128 reports vLLM serving mlx-community/Qwen3.6-27B-bf16 rejects every request with:

ERROR: POST http://1.2.3.4:8000/v1/chat/completions
Caused by: 404 Not Found Reason: {"error": "System message must be at the beginning."}

MergeSystemMessages already exists for this case. The transformer doc comment even says "Some providers (e.g. NVIDIA) reject requests with multiple system messages or system messages that are not positioned at the start". The "e.g." anticipated more cases, but the gating predicate at crates/forge_app/src/dto/openai/transformers/pipeline.rs:86 only matched NVIDIA.

vLLM is a built-in provider (registered in crates/forge_repo/src/provider/provider.json as id "vllm"), so it has its own ProviderId and goes through the openai pipeline. The fix adds it to the same predicate.

Changes

• crates/forge_app/src/dto/openai/transformers/pipeline.rs: predicate now matches ProviderId::NVIDIA or the vLLM provider id (resolved via ProviderId::from_str("vllm") in the same style as the existing kimi_coding binding a few lines below).
• crates/forge_app/src/dto/openai/transformers/ensure_system_first.rs: doc comment now lists vLLM alongside NVIDIA.

The transformer is a no-op for already-compliant requests (single system message at the start), so no behavior changes for users whose vLLM server already gets correct input.

Testing

• New pipeline-level test test_vllm_provider_merges_system_messages asserts that a vLLM provider with mixed system messages produces a single merged system message at the front.
• cargo test -p forge_app: 696 passed, 0 failed.
• cargo clippy -p forge_app --all-targets --all-features -- -D warnings: clean.

Closes #3128

[CLAassistant]

All committers have signed the CLA.

[amitksingh1490]

vLLM is a builtin provider

[tmchow]

Predicate now matches NVIDIA + vLLM (not OPENAI_COMPATIBLE). Updated pr desc.

[YoyoSailer]

Just jumping in - I have a problem with this approach as it is hardcoded to have vllm. I have hosted it behind nginx proxy and have a little middlewear and accessing it from a URL and AUTH so i used OpenAI Compatible.

My vLLM worked fine on other tools.

I guess I should use VLLM but for that I do not have PORT :) Let me open a new ticket for that.

Just to put here, I have fixed that in my middleware as well

// Qwen3 chat template requires system message at index 0 only.
// Merge any mid-conversation system messages into a single leading block.
  const systems = req.body.messages.filter(m => m.role === 'system');
  if (systems.length > 1 || (systems.length === 1 && req.body.messages[0].role !== 'system')) {
    const others = req.body.messages.filter(m => m.role !== 'system');
    const mergedContent = systems
      .map(m => (typeof m.content === 'string' ? m.content : JSON.stringify(m.content)))
      .filter(Boolean)
      .join('\n\n');
    req.body.messages = [{ role: 'system', content: mergedContent }, ...others];
  }

It just move all system messages to one place.

[tmchow]

Thanks @YoyoSailer for the context (and the middleware snippet). Sounds like the vLLM path works for you with VLLM_PORT now that #3258 landed.

Rebased onto main in 34e0e3d to clear the merge-behind state. @amitksingh1490 @laststylebender14 anything else on this one?