### Apache Airflow version

2.7.0

### What happened

Relates to investigation of #30327

When you define a DAG with a `schedule=datetime.timedelta(days=1)` and `catchup=False` and you manually trigger a run in the past (logical date in the past, e.g. a few days ago) then upon completion of the run another scheduled run is triggered - irrespective of a previous scheduled run was made just before (not a day ago)

### What you think should happen instead

A manual run should not trigger another run as the scheduling in general should follow the delta time definition of the DAG.

### How to reproduce

Use the following example DAG code and enable scheduling:
```
with DAG(
    dag_id="after_workday_delta_regression",
    start_date=pendulum.datetime(2023, 8, 1, tz="UTC"),
    catchup=False,
    schedule=datetime.timedelta(days=1),
    params={"test": 123}
):
    @task
    def test(ti: TaskInstance=None):
        print(ti.execution_date)
    test()
```

Wait a moment and see that one schedule is run automatically.
Then trigger a manual DAG run and set the execution date/logical date a few days into the past.
After execution you see a third run of the DAG just at the time of completion of the manual trigger as execution date. But the first execution was just a few moments before, not respecting the desired delta of 1 day.

### Operating System

Ubuntu 20.04 / Breeze Dev setup in Py 3.8 Container

### Versions of Apache Airflow Providers

not relevant

### Deployment

Other

### Deployment details

Started and tested with latest main branch and breeze.

### Anything else

I tried to find the root cause but was not able to locate it. Suspect it is rooted in scheduler_job_runner.py.
I'd supply a fix but was not able to fund the root cause. Expert knowledge is needed probably.

### 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)

that only one scheduler can "process them", even it is waiting behind other dags. Increasing this
          limit will allow more throughput for smaller DAGs but will likely slow down throughput for larger
          (>500 tasks.) DAGs
        - Then, via a Critical Section (locking the rows of the Pool model) we queue tasks, and then send them
          to the executor.
          See docs of _critical_section_enqueue_task_instances for more.
        :return: Number of TIs enqueued in this iteration
        """
        
        with prohibit_commit(session) as guard:
            if settings.USE_JOB_SCHEDULE:
                self._create_dagruns_for_dags(guard, session)
            self._start_queued_dagruns(session)
            guard.commit()
            dag_runs = self._get_next_dagruns_to_examine(DagRunState.RUNNING, session)
            
            
            callback_tuples = self._schedule_all_dag_runs(guard, dag_runs, session)
        
        
        cached_get_dag: Callable[[str], DAG | None] = lru_cache()(
            partial(self.dagbag.get_dag, session=session)
        )
        for dag_run, callback_to_run in callback_tuples:
            dag = cached_get_dag(dag_run.dag_id)
            if dag:
                
                
                self._send_dag_callbacks_to_processor(dag, callback_to_run)
            else: