docs: align cronjob nodepool docs with required affinity behavior

docs/configuration/cronjob.mdx

@@ -18,11 +18,16 @@ Cron Jobs in Qovery are Kubernetes workloads that run on a regular schedule. The
 ## Dedicated Cronjob Node Pool
 
 <Info>
-On AWS EKS clusters with Karpenter, you can enable a dedicated **cronjob node pool**. When enabled, a Karpenter NodePool named `cronjob` is created with a `nodepool/cronjob: NoSchedule` taint. Qovery cron jobs automatically receive the appropriate toleration and a preferred node affinity toward this node pool, so they are steered there when available. See [AWS EKS cluster resources](/configuration/integrations/kubernetes/eks/managed#resources) for details on enabling and configuring this nodepool.
+On AWS EKS clusters with Karpenter, you can enable a dedicated **cronjob node pool**. When enabled, a Karpenter NodePool named `cronjob` is created with a `nodepool/cronjob: NoSchedule` taint. Qovery cron jobs automatically receive the appropriate toleration and a required node affinity toward this node pool, so they always run there. See [AWS EKS cluster resources](/configuration/integrations/kubernetes/eks/managed#resources) for details on enabling and configuring this nodepool.
 </Info>
 
 <Warning>
-After enabling or disabling the cronjob node pool, **we strongly recommend redeploying all your cron jobs** to ensure they pick up the updated scheduling configuration. If the nodepool is removed before jobs are redeployed, existing cron jobs can fall back to the default nodepool instead of staying in `Pending`, but redeploying ensures they run with the latest intended scheduling behavior.
+Whenever you enable or disable the cronjob node pool, **you must redeploy every cron job** so they pick up the updated scheduling configuration. The node affinity is required (hard), so:
+
+- Cron jobs deployed **before** the nodepool was enabled will not run on it until they are redeployed.
+- Cron jobs deployed **while** the nodepool was enabled will stay in `Pending` if the nodepool is later disabled and they are not redeployed.
+
+There is no automatic fallback to the default node pool. Always redeploy your cron jobs after touching this setting.
 </Warning>
 
 ## Deployment Sources

docs/configuration/integrations/kubernetes/eks/managed.mdx

@@ -255,7 +255,7 @@ Qovery deploys two node pools by default:
 Additional optional node pools can be enabled:
 
 - **GPU node pool**: Can be enabled if you want to run GPU workloads on your cluster. You can select the GPU instance types you want to use on this nodepool.
-- **Cronjob node pool**: A dedicated node pool for Qovery cron jobs. When enabled, a Karpenter NodePool named `cronjob` is created with a `nodepool/cronjob: NoSchedule` taint. Qovery cron jobs automatically receive the appropriate toleration and a preferred node affinity toward this nodepool, so they are steered there when available. This helps isolate cronjob workloads from long-running services on shared nodes. The cronjob nodepool supports consolidation scheduling and resource limits (same as the stable nodepool). After enabling or disabling this nodepool, **we strongly recommend redeploying all your cron jobs** to ensure they run with the latest intended scheduling configuration. If the nodepool is removed before redeploy, existing jobs can fall back to the default nodepool instead of staying in `Pending`.
+- **Cronjob node pool**: A dedicated node pool for Qovery cron jobs. When enabled, a Karpenter NodePool named `cronjob` is created with a `nodepool/cronjob: NoSchedule` taint. Qovery cron jobs automatically receive the appropriate toleration and a required node affinity toward this nodepool, so they always run there. This helps isolate cronjob workloads from long-running services on shared nodes. The cronjob nodepool supports consolidation scheduling and resource limits (same as the stable nodepool). The node affinity is required (hard): whenever you enable or disable this nodepool, **you must redeploy every cron job** so they pick up the updated scheduling configuration. There is no automatic fallback to the default node pool. Cron jobs deployed before the nodepool was enabled will not run on it until they are redeployed, and cron jobs deployed while the nodepool was enabled will stay in `Pending` if the nodepool is later disabled and they are not redeployed.
 
 #### Settings for nodepools: