Support request serving node and autosclaing topology on EKS management clusters

HyperShift uses dedicated request serving nodes on the management cluster to host Kubernetes API Server pods for hosted clusters. These nodes are isolated via labels, taints, and scheduling constraints to ensure predictable performance, security boundaries, and proper resource allocation for serving API requests.  This RFE requests that the request serving node model is supported on EKS management clusters, including:
  - Provisioning and managing request serving nodes on EKS (via managed node groups, Karpenter, or auto-scaling groups)
  - Applying the correct labels, taints, and topology constraints so that KAS pods are scheduled exclusively onto designated request serving nodes
  - Ensuring node sizing, scaling, and lifecycle management align with EKS-native primitives
  - Supporting per-hosted-cluster isolation guarantees on EKS request serving nodes  This is a prerequisite for running production ROSA HCP workloads on EKS management clusters, where API server availability and performance SLAs depend on dedicated request serving infrastructure. 

Production readiness for rosa-regional-platform which uses EKS management clusters: Request serving node isolation is a requirement.