Auto-add nvidia.com/gpu toleration to GPU JupyterHub profiles

Background

nebari-dev/nebari-infrastructure-core#370 makes NIC automatically taint AWS GPU node groups with nvidia.com/gpu=true:NoSchedule, so ordinary pods stay off GPU nodes.

Nothing injects the matching toleration for us on EKS:

• The NVIDIA GPU Operator only tolerates this taint on its own operands (driver, device plugin), not on user pods.
• The Kubernetes ExtendedResourceToleration admission controller would auto-tolerate pods that request nvidia.com/gpu, but it is not enabled on EKS and cannot be enabled on the managed control plane. AWS's own GPU guide hand-writes the toleration on every example pod for this reason.

So once #370 lands, a JupyterHub GPU profile will stop scheduling new servers onto GPU nodes unless the profile carries the toleration.

Request

Auto-add a toleration for nvidia.com/gpu to any JupyterHub/KubeSpawner profile that targets GPUs, so users do not have to hand-write it. A GPU profile is one that requests nvidia.com/gpu in its resources, or is otherwise marked as a GPU profile (for example a GPU node selector). The injected toleration should be:

tolerations:
- key: "nvidia.com/gpu"
  operator: "Exists"
  effect: "NoSchedule"

operator: Exists keeps it working regardless of the taint value, so it matches both NIC's value: "true" and other values.

Acceptance criteria

• A GPU profile launched against a cluster whose GPU nodes carry nvidia.com/gpu=true:NoSchedule schedules onto the GPU node and starts.
• Non-GPU profiles are unchanged and gain no toleration.
• Inside a running GPU server, the GPU is visible (nvidia-smi, CUDA available to the framework).

Blocks

This blocks nebari-dev/nebari-infrastructure-core#370. The taint change should not roll out until GPU profiles tolerate the taint, otherwise GPU notebooks break.