Store executor callback DagRun references in the database

[fat-catTW]

Why

Executor callbacks need to know which DagRun they belong to when the scheduler
builds callback workloads. Keeping that reference only in callback.data makes
the scheduler depend on payload shape instead of a database-managed relationship.

Solution

Add a nullable callback.dagrun_id foreign key to dag_run.id and have executor
callbacks store their DagRun reference there. The scheduler now loads the
relationship through the ORM when enqueueing callback workloads.

The migration backfills existing rows from deadline relationships first, then
falls back to legacy callback payload data when needed.

Was generative AI tooling used to co-author this PR?

• [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.

[uranusjr]

This collapses two previously distinct failure modes (missing dagrun_id due to a callback-creation bug vs. a DagRun deleted after enqueue) into one warning path. Only one production call site sets dagrun_id today, so it's not reachable now, but it'd be easy for a future ExecutorCallback creation path to forget to set it and silently emits "DagRun may have been deleted."

Maybe add different checks to callback.dagrun_id is None and dag_run is None with dagrun_id set?