Dataset Aware scheduling ignores catchup and leads to surprising behaviour when downstream DAG is deactivated

### Apache Airflow version Other Airflow 2 version (please specify below) ### If "Other Airflow 2 version" selected, which one? 2.10.x ### What happened? We were aware of this change https://github.com/apache/airflow/pull/38891 while upgrading to 2.10, which solves some problems/expectations reported here: https://github.com/apache/airflow/issues/38826 Unfortunately, it broke for in quite weird circumstances. We are working of improvements on our end, but we believe it's actually unexpected behaviour of the feature. We have got many DAGs in single instance (close to 2k) and we have deployment process to K8s, with image without DAGs, they are only subsequently synced. We also have `dag_processor` enabled. What is happening is one of two things: * The `dag_processor` decides to remove DAGs which have not been parsed for some time, due to many DAGs/slow parsing * The DAGs are deactivated during the Airflow startup. At this moment any `dataset` producing task which finishes while the downstream Dataset scheduled DAG is deactivated will produce event which will be ignored. It will be only picked up during subsequent execution, but it can lead to delays. I was reading the conversation that the `catchup` flag is not used and I feel like this is the problem for us - it intuitively doesn't make sense it is ignored, i.e. I wouldn't expect DAG to pick up more Dataset on subsequent trigger, rather as soon as possible. ### What you think should happen instead? I believe either one of two things should happen: * If `catchup` is configured, the DAG should be scheduled immediately when it is activated/appears.This would be consistent behaviour of Time scheduling and catchup parameter. * OR maybe the change introduced in https://github.com/apache/airflow/pull/38891 could be relaxed and still trigger deactivated DAGs (only paused could be ignored?). Any other ideas? We are obviously working on hour end to avoid long parsing/deactivations, but I believe this behaviour is quite c…