Using @task.kubernetes decorator in a dag causes different dag hash on every serialized dag update

### Apache Airflow Provider(s) cncf-kubernetes ### Versions of Apache Airflow Providers apache-airflow-providers-cncf-kubernetes==9.0.1 ### Apache Airflow version 2.10.5 ### Operating System Linux ### Deployment Other 3rd-party Helm chart ### Deployment details **Airflow Compute:** GKE - **scheduler replicas:** 2 **Airflow Meta Database:** MySQL 8.0.31 **Main Airflow configuration:** _executor:_ KubernetesExecutor _AIRFLOW__SCHEDULER__SCHEDULE_AFTER_TASK_EXECUTION:_ False _AIRFLOW__CORE__MAX_NUM_RENDERED_TI_FIELDS_PER_TASK:_ 0 _AIRFLOW__CORE__PARALLELISM:_ 250 ### What happened Using @task.kubernetes in a DAG causes dag hash to change every time serialized dag update occurs based on AIRFLOW__CORE__MIN_SERIALIZED_DAG_UPDATE_INTERVAL. The change in dag hash for every serialized dag update only occurs when multiple schedulers are configured. In my case I have 2 schedulers so I see the dag hash flip flop between two different values. After troubleshooting and going through the Airflow 2.10.5 source code, I see the root cause of the issue to be [this code statement](https://github.com/apache/airflow/blob/b93c3db6b1641b0840bd15ac7d05bc58ff2cccbf/airflow/providers/cncf/kubernetes/decorators/kubernetes.py#L60) `template_fields: Sequence[str] = tuple( {"op_args", "op_kwargs", *KubernetesPodOperator.template_fields} - {"cmds", "arguments"} )` template_fields are initialized using set which has non-deterministic order which results into different dag hash on different scheduler. The frequent change in dag hash amplifies update dag_run statements during scheduling `UPDATE `dag_run` SET `last_scheduling_decision` = ?, `dag_hash` = ?, `updated_at` = ? WHERE `dag_run` . `id` = ?` `UPDATE `dag_run` SET `last_scheduling_decision` = ?, `updated_at` = ? WHERE `dag_run` . `id` = ?` `UPDATE `dag_run` SET `dag_hash` = ?, `updated_at` = ? WHERE `dag_run` . `id` = ?` This additional updates causes more lock waits in the database. This especially beco…