### What do you see as an issue?

The documentation for zombie tasks https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/tasks.html#zombie-undead-tasks is a bit abstract at the moment. There is a scope for enhancing the document by explaining how Airflow detects tasks as zombies

### Solving the problem

We can enhance the documentation by translating this query https://github.com/astronomer/airflow/blob/main/airflow/jobs/scheduler_job_runner.py#L1721 to a layman readable text in our documentation.

### Anything else

It might also help to add developer contribution steps to reproduce zombies locally.

### Are you willing to submit PR?

- [ ] Yes I am willing to submit a PR!

### Code of Conduct

- [X] I agree to follow this project's [Code of Conduct](https://github.com/apache/airflow/blob/main/CODE_OF_CONDUCT.md)

time.sleep(min(self._scheduler_idle_sleep_time, next_event or 0))
            if loop_count >= self.num_runs > 0:
                self.log.info(
                    "Exiting scheduler loop as requested number of runs (%d - got to %d) has been reached",
                    self.num_runs,
                    loop_count,
                )
                break
            if self.processor_agent and self.processor_agent.done:
                self.log.info(
                    "Exiting scheduler loop as requested DAG parse count (%d) has been reached after %d"
                    " scheduler loops",
                    self.num_times_parse_dags,
                    loop_count,
                )
                break
    def _do_scheduling(self, session: Session) -> int:
        """
        Make the main scheduling decisions.
        It:
        - Creates any necessary DAG runs by examining the next_dagrun_create_after column of DagModel
          Since creating Dag Runs is a relatively time consuming process, we select only 10 dags by default
          (configurable via ``scheduler.max_dagruns_to_create_per_loop`` setting) - putting this higher will
          mean one scheduler could spend a chunk of time creating dag runs, and not ever get around to
          scheduling tasks.
        - Finds the "next n oldest" running DAG Runs to examine for scheduling (n=20 by default, configurable
          via ``scheduler.max_dagruns_per_loop_to_schedule`` config setting) and tries to progress state (TIs
          to SCHEDULED, or DagRuns to SUCCESS/FAILURE etc)
          By "next oldest", we mean hasn't been examined/scheduled in the most time.
          We don't select all dagruns at once, because the rows are selected with row locks, meaning