Optimize DAG list query for users with limited access

[kaxil]

When users have limited DAG access, the DAG list query was inefficiently grouping all DagRuns in the database before filtering. This caused severe performance degradation in large deployments where a user might access only a few DAGs out of hundreds or thousands.

The fix filters both the main DAG query and the DagRun subquery by accessible dag_ids before performing the expensive GROUP BY operation.

Before (queries all dagruns):

  SELECT ... FROM dag
  LEFT OUTER JOIN (
    SELECT dag_run.dag_id, max(dag_run.id) AS max_dag_run_id
    FROM dag_run
    GROUP BY dag_run.dag_id
  ) AS mrq ON dag.dag_id = mrq.dag_id

After (filters to accessible dags):

  SELECT ... FROM dag
  LEFT OUTER JOIN (
    SELECT dag_run.dag_id, max(dag_run.id) AS max_dag_run_id
    FROM dag_run
    WHERE dag_run.dag_id IN ('accessible_dag_1', 'accessible_dag_2')
    GROUP BY dag_run.dag_id
  ) AS mrq ON dag.dag_id = mrq.dag_id
  WHERE dag.dag_id IN ('accessible_dag_1', 'accessible_dag_2')

Performance impact: In a deployment with 100 DAGs (100 runs each) where a user has access to only 2 DAGs, this reduces the subquery from grouping 10,000 rows down to 200 rows (50x improvement), and eliminates fetching 98 unnecessary DAG models.

Fixes #57427

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[tirkarthi]

Thanks @kaxil , we had a very similar patch tested with a shared cluster used by multiple teams with varied count of accessible dags. The group by logs that examined all the rows stopped occuring in the MySQL slow query logs after the fix.

[github-actions]

Backport failed to create: v3-1-test. View the failure log Run details

Status	Branch	Result
❌	v3-1-test

You can attempt to backport this manually by running:

cherry_picker f271f2b v3-1-test

This should apply the commit to the v3-1-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue