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

"""
        Mark tasks stuck in queued for longer than `task_queued_timeout` as failed.
        Tasks can get stuck in queued for a wide variety of reasons (e.g. celery loses
        track of a task, a cluster can't further scale up its workers, etc.), but tasks
        should not be stuck in queued for a long time. This will mark tasks stuck in
        queued for longer than `self._task_queued_timeout` as failed. If the task has
        available retries, it will be retried.
        """
        self.log.debug("Calling SchedulerJob._fail_tasks_stuck_in_queued method")
        tasks_stuck_in_queued = session.scalars(
            select(TI).where(
                TI.state == TaskInstanceState.QUEUED,
                TI.queued_dttm < (timezone.utcnow() - timedelta(seconds=self._task_queued_timeout)),
                TI.queued_by_job_id == self.job.id,
            )
        ).all()
        try:
            tis_for_warning_message = self.job.executor.cleanup_stuck_queued_tasks(tis=tasks_stuck_in_queued)
            if tis_for_warning_message:
                task_instance_str = "\n\t".join(tis_for_warning_message)
                self.log.warning(
                    "Marked the following %s task instances stuck in queued as failed. "
                    "If the task instance has available retries, it will be retried.\n\t%s",
                    len(tasks_stuck_in_queued),
                    task_instance_str,
                )
        except NotImplementedError:
            self.log.debug("Executor doesn't support cleanup of stuck queued tasks. Skipping.")
            ...