Add pod scheduling controls: nodeSelector, tolerations, affinity, topologySpreadConstraints

[tartkri-bot]

Problem

The predictor topology currently does not expose pod scheduling controls (nodeSelector, tolerations, affinity, topologySpreadConstraints). The only scheduling hint available is comp.Resources which gets passed to the container — useless if you need to target specific node pools (e.g., GPU nodes, spot instances, dedicated nodes for compliance).

The LLM topology at least has the config baseRef escape hatch; predictor has nothing.

Concrete use cases

1. GPU targeting: Deploy an LLM on a node with nvidia.com/gpu and a predictor on CPU-only nodes — scheduler needs nodeSelector or affinity.
2. Spot / preemptible instances: Toleration cloud.google.com/gke-spot: "true" or k8s.azure.com/scalesetpriority: spot.
3. Multi-zone HA: podAntiAffinity to spread replicas across zones, or topologySpreadConstraints to ensure even distribution.
4. Dedicated / tainted nodes for isolation: Model serving for a specific client on a dedicated node pool with custom taints.

Suggested approach

Add to ModelServerCustomSpec:

• nodeSelector — map[string]string.
• tolerations — []corev1.Toleration.
• affinity — corev1.Affinity.
• topologySpreadConstraints — []corev1.TopologySpreadConstraint.

For LLM topology, also expose these as first-class fields (they can already be set via config, but that's not discoverable).

Acceptance criteria

• nodeSelector is propagated to the InferenceService / LLMInferenceService workload spec.
• tolerations are propagated to pods via KServe.
• affinity (nodeAffinity, podAffinity, podAntiAffinity) is supported.
• topologySpreadConstraints are supported.
• Provider validation rejects invalid affinity / topologySpreadConstraints where possible.
• Chainsaw tests verify scheduling on nodes with specific labels/taints.