Expose model criticality for gateway scheduling

[spron-in]

Problem. LLMModelSpec.Criticality (Critical / Standard / Sheddable) is not exposed. The Inference Gateway scheduler uses it to prioritize and shed load between models.

Impact. In multi-tenant / multi-model clusters there's no way to mark which models get served first under pressure; all traffic is treated equally.

Current workaround. None.

Upstream. Model.Criticality, consumed by the EPP scheduler.

Scope. A criticality field on llmEngine (only meaningful with gateway routing).

[atharvamhaske]

LLMModelSpec.Criticality (the Critical/Standard/Sheddable enum) came from kserve's v1alpha1 API, which mirrored GIE's old InferenceModel.Criticality. Upstream renamed that field before kserve ever moved to v1alpha2: GIE#1363 replaced the enum with a plain *int priority, and GIE#1255 renamed InferenceModel to InferenceObjective shortly after. When kserve bumped GIE to v1.2.0 in kserve#4886 and cut v1alpha2, it picked up the post-rename API, so Criticality just never carried over. It's still around in v1alpha2 as an internal annotation used only for v1alpha1 conversion — nothing reads it.

Two more things worth knowing before this gets implemented:

kserve's LLMInferenceService controller doesn't create InferenceObjective objects at all right now, even though its RBAC already allows it. It does create a deterministically named InferencePool (-inference-pool) per instance, so a downstream provider could create the InferenceObjective itself and point it at that pool without any kserve change.
Priority is picked per request, not per model — a caller sets the x-gateway-inference-objective header naming the object they want. There's no built-in "this model always gets priority N" binding. So whatever we build needs a plan for who sets that header, or the field won't do anything for most traffic.

Proposed scope: add priority *int32 (matching upstream's type, not the old enum) to llmEngine, gated on enableGatewayRouting. The provider creates a sibling InferenceObjective pointed at kserve's InferencePool. Header injection is a separate piece of work, probably belongs in an AI Gateway policy rather than here.

[atharvamhaske]

holding on due to upstream envoy ai gateway gap of headermutation for inference pool