vLLM-Omni has no parity pin: H3 W3+, LTX-2.5 and ~40 omni-only architectures (the whole TTS family included) cannot be gated against any oracle

[localai-bot]

Gap

The upstream-sync protocol pins exactly one repository: vLLM itself, currently
5559679229bc961848b121ccdeaa8fa5d79bec98 (0.26.0.dev0). It has no concept of a
pin for vllm-project/vllm-omni, which is a separate repository with its own
release cadence and its own model registry.

Consequence: every architecture that exists only in vllm-omni is un-gateable. Not
"hard to gate" — there is no protocol-legal way to name the oracle it would be
compared against.

This is already recorded as blocking work:

• .agents/specs/minimax-h3.md:205-208 — "The parity pin (555967922, vLLM
  0.26.0.dev0) does NOT contain MiniMax-H3 ... it lives in the separate
  vllm-omni repository, which the pin protocol does not currently cover.
  Advancing the pin does not by itself make H3 gateable; a vllm-omni pin is a
  prerequisite for W3+."
• .agents/model-matrix.md (MODEL-DIFFUSION-minimax-h3-mini-max-h3-dit) ends
  with: "OPEN: there is no vllm-omni parity PIN — the upstream-sync protocol
  covers only the vLLM repo".
• LTX-2.5: port the 21B joint video+audio DiT and generalize the video seam #435 (LTX-2.5) needs the same thing.

The gap is much larger than three rows

vllm_omni/model_executor/models/ registers roughly 40 model modules that have
no counterpart in the vLLM registry our 329-row inventory was derived from —
including an entire speech-synthesis family (IndexTTS2, Fish Speech, GLM-TTS,
Ming-TTS, MOSS-TTS, Qwen3-TTS, VoxCPM2, Voxtral-TTS, Higgs Audio v2/v3,
Step Audio2, CosyVoice3, OmniVoice) plus Qwen2.5/3-Omni, Aura-Omni,
Ming-Flash-Omni, Hunyuan Image3/Video and others.

So this is not only a pin: .agents/model-matrix.md claims an exhaustive
architecture inventory, and that claim is currently scoped to one repo without
saying so. The omni surface is uninventoried and uncounted.

What this issue covers

1. Extend .agents/upstream-sync.md with a second pin — a vllm-omni commit plus
   the vLLM core version that commit requires — and define how the two interact,
   including the case that matters immediately: vllm-omni needs vLLM 0.27.0+
   while our core pin is 0.26.0.dev0.
2. Carry the existing gateability rule across unchanged: an omni oracle counts
   only once it demonstrably builds and runs the model. Constructing a config
   proves nothing.
3. State in model-matrix.md that its exhaustive claim is vLLM-repo-scoped, and
   record the omni surface as a known, separately-pinned inventory obligation.

Out of scope

Advancing the vLLM core pin to 0.27.0+. That touches every gated row and every
binding benchmark and needs its own spec and reconciliation; this issue must
leave the two advances separable.

Not yet decided

Whether a vllm-omni pin advance requires re-running the vLLM-side binding grids.
The spec has to answer this explicitly rather than leave it to be discovered.