[Rust Frontend] Add Harmony Renderer for GPT-OSS

[BugenZhao]

Purpose

Add a native Harmony chat renderer for GPT-OSS in the Rust frontend.

With this change, RendererSelection::Auto chooses the new Harmony renderer when model_type == "gpt_oss". The renderer uses oss-harmony to render the Chat Completions input directly into Prompt::TokenIds, matching the existing Harmony output processor path and avoiding the generic Jinja/HF rendering path for GPT-OSS.

The renderer covers the current Rust Chat Completions surface:

• leading system/developer instructions, including the VLLM_SYSTEM_START_DATE and VLLM_GPT_OSS_HARMONY_SYSTEM_INSTRUCTIONS behavior
• reasoning_effort validation for Harmony-supported values
• request-level and developer-local function tools
• assistant reasoning/final/commentary/tool-call history
• tool responses mapped back through assistant tool-call IDs
• Python-parity stale analysis dropping before calling into oss-harmony

The existing HF renderer remains available through explicit --chat-renderer hf selection for debugging and comparison.

Test Plan

• cargo fmt --manifest-path rust/Cargo.toml --all -- --check
• cargo nextest run --manifest-path rust/Cargo.toml -p vllm-chat harmony
• cargo nextest run --manifest-path rust/Cargo.toml -p vllm-chat renderer
• cargo nextest run --manifest-path rust/Cargo.toml -p vllm-chat output::harmony
• cargo check --manifest-path rust/Cargo.toml -p vllm-chat --locked
• cargo doc --manifest-path rust/Cargo.toml -p vllm-chat --no-deps --locked

Test Result

All focused Rust commands passed locally.

cargo doc completed successfully. It reports three pre-existing rustdoc private-link warnings outside the Harmony renderer, in rust/src/chat/src/lib.rs and rust/src/chat/src/output/default/mod.rs.

Ad hoc fixture comparison against the current Python Harmony path matched the simple, leading-instruction, request-tool, assistant-history, and stale-analysis cases. The remaining differences are intentional/current gaps: Rust preserves developer-local tools expressed in the Rust request schema, and Rust follows oss-harmony v0.0.11 / <|constrain|>json tool-call rendering while the local Python environment used openai-harmony 0.0.8.

GB200 E2E smoke validation passed.

---

Essential Elements of an Effective PR Description Checklist

• The purpose of the PR, such as "Fix some issue (link existing issues this PR will resolve)".
• The test plan, such as providing test command.
• The test results, such as pasting the results comparison before and after, or e2e results
• (Optional) The necessary documentation update, such as updating supported_models.md and examples for a new model.

[BugenZhao]

This change is part of the following stack:

• [Rust Frontend] Use oss-harmony for Harmony output processing #46799
  • [Rust Frontend] Add Harmony Renderer for GPT-OSS #46800 ◀

_{Change managed by git-spice.}

[claude]

Claude Code Review

This repository is configured for manual code reviews. Comment @claude review to trigger a review and subscribe this PR to future pushes, or @claude review once for a one-time review.

_{Tip: disable this comment in your organization's Code Review settings.}