[feat] provider: wire the capability contract into the vLLM-Omni precheck path #340

Follow-up to #278, which added domain/capability_contract.py — the parser for the omni.capabilities envelope (/v1/omni/capabilities, schema_version 1) — with no production call site. That was the intended shape of #278: a self-contained parser, integration explicitly out of scope. This issue tracks the wiring.

Why it is not in #278. Nothing in this repository obtains the omni.capabilities document yet. The only /capabilities surface is POST /api/model-configs/capabilities, which returns the videoCapabilities output-spec extension of GET /models — a different document from the one the parser reads. The producer is #266's discovery, which is open and still conflicting.

Target call site. VllmOmniGeneration.prepare_inputs (packages/core/src/opendirector/integrations/vllm_omni.py:61), where the first_frame / reference / continuation three-way is already decided. resolve() turns the declaration into per-capability availability; required_roles_for() and role_verdict() decide which of source_video / video_noise_mask / audio_noise_mask a request must carry.

Acceptance

• the declaration document obtained by feat(providers): discover capabilities and validate generation inputs #266's discovery reaches resolve() on the precheck path, with no second fetch of the same document
• validate() refuses a request whose required roles the declaration does not support, using the contract's own reason codes (unsupported / route_disabled / role_not_declared / …)
• a test drives the precheck from a real declaration payload rather than a hand-built one
• no behavioural change when the service publishes no omni.capabilities document (the verdict stays unknown)

Out of scope. Changing what #278 delivers; any adapter or UI surface for the capability matrix.

Depends on: #266.