Isolate scheduled DagRun creation failures with savepoints

[fat-catTW]

Why

SchedulerJobRunner._create_dag_runs catches exceptions while creating scheduled DagRuns and then continues with the next Dag. This does not work reliably when the failure is caused by a database error, because the SQLAlchemy session can be left in a failed transaction state.

When that happens, one failing DagRun creation attempt can prevent the scheduler from creating DagRuns for other healthy Dags in the same batch.

Solution

Wrap each scheduled DagRun creation attempt in a nested transaction/savepoint. If a database-level failure happens for one Dag, only that DagRun creation attempt is rolled back and the outer scheduler transaction remains usable.

The in-memory active run counter is updated only after the savepoint succeeds, keeping scheduler state aligned with the database transaction outcome.

A regression test covers a flush-time database failure for one Dag and verifies that another Dag in the same batch still creates its DagRun successfully.

relates: #59120

• [X] Yes (please specify the tool below)

Generated-by: [Codex] following the guidelines

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

[steveahnahn]

Nice work! Reverting the savepoint wrapping reproduces the poisoned-transaction failure and the fix clears it LGTM aside from the one nit