KPO pods can hang if sidecar never exits

### Apache Airflow Provider(s) cncf-kubernetes ### Versions of Apache Airflow Providers all versions ### Apache Airflow version all versions ### Operating System linux ### Deployment Astronomer ### Deployment details this can happen on any deployment type / executor as it's an issue with KPO. ### What happened tl;dr KPO sometimes hang around long after their corresponding TI has reached a terminal state. sometimes the xcom sidecar never exits leaving zombie KPO pods around indefinitely. this could also happen if the user defines a pod with a sidecar that never exits and ignores signals. A KubernetesPodOperator (KPO) pod is considered a zombie if any of the following apply: 1. It doesn't match any active (non-terminal) task instance in the database 2. The pod's `try_number` is less than the matching active task instance's current `try_number` (old retry pod) ### What you think should happen instead There should be some clean-up logic perhaps in the scheduler, instead of the operator clean up itself to force kill zombie KPO pods. similar to that which cleans up Kubernetes Executor zombies (gated by the configurations below) AIRFLOW__KUBERNETES_EXECUTOR__DELETE_WORKER_PODS AIRFLOW__KUBERNETES_EXECUTOR__DELETE_WORKER_PODS_ON_FAILURE 1. **List all KPO pods**: Uses Kubernetes API with label selector `kubernetes_pod_operator=True` 2. **Extract TI details from pods**: For each pod, extracts normalized task instance details from labels (`dag_id`, `task_id`, `run_id`, `map_index`, `try_number`). Pod labels are already normalized by Airflow using `make_safe_label_value()` 3. **Query active task instances**: Queries all active (non-terminal) task instances from the database in a single batch query, filtering for KubernetesPodOperator-related operators (KubernetesPodOperator, KubernetesPodOperatorAsync, SparkKubernetesPodOperator, etc., but excluding "external" EksPodOperator and GKEStartPodOperator) 4. **Normalize DB values to pod label format**: Normalizes database values…