* Fix airflow db clean never purging the callback table

The table was renamed from callback_request in Airflow 3.2.0 and the
cleanup configuration was not updated with it. A configured table that
does not exist is skipped with only a warning, so these rows were never
deleted and the table grew without bound, with no way for an operator to
purge it.

Only callbacks that can no longer run are removed. A callback still
awaiting execution owns its deadline row through an ON DELETE CASCADE
foreign key, so deleting one would silently drop a deadline that has not
fired yet.

The sla_miss entry is dropped as well, since that table no longer exists
in Airflow 3.

* Purge orphaned partitioned_asset_key_log rows and restore the db clean coverage check

The check that is meant to catch a metadata table being left out of
airflow db clean looked for the models package at a path relative to the
test file. That path stopped resolving when the sources moved under
airflow-core, so the check examined no models at all and its assertions
held trivially for an empty set. It has not been able to report a missing
table since, which is how the callback table went unpurged for several
releases.

Walking the package's own search path instead keeps the check working
wherever the sources live, and asserting that models were found stops it
from passing on an empty set again.

With the check restored, partitioned_asset_key_log is the one table it
reports that genuinely has no way to be purged: it carries no foreign
key, so its rows are left behind when the partition Dag run they describe
is cascade-deleted with its dag_run. Only those orphans are deleted --
rows whose partition Dag run still exists are the evidence the scheduler
evaluates to decide when that pending run fires, so they are kept
regardless of age. The other uncovered tables are recorded in the
exclusion list with the reason each is safe.

* Purge orphaned scheduled callbacks while keeping unfired deadlines in db clean

Every callback starts in SCHEDULED, a state outside both the active and the
terminal sets, and an unfired deadline's callback stays there until the deadline
is missed. Deny-listing active states would therefore purge those callbacks and,
through the ON DELETE CASCADE foreign key, silently drop deadlines that have not
fired. The finished states stay allow-listed, so an unknown state keeps its rows.
A SCHEDULED callback is purged only once no deadline references it: deleting a
Dag run cascades away its deadline at the database level, which leaves the
callback behind forever.

(cherry picked from commit 478745a)

* Fix airflow db clean never purging the callback table

The table was renamed from callback_request in Airflow 3.2.0 and the
cleanup configuration was not updated with it. A configured table that
does not exist is skipped with only a warning, so these rows were never
deleted and the table grew without bound, with no way for an operator to
purge it.

Only callbacks that can no longer run are removed. A callback still
awaiting execution owns its deadline row through an ON DELETE CASCADE
foreign key, so deleting one would silently drop a deadline that has not
fired yet.

The sla_miss entry is dropped as well, since that table no longer exists
in Airflow 3.

* Purge orphaned partitioned_asset_key_log rows and restore the db clean coverage check

The check that is meant to catch a metadata table being left out of
airflow db clean looked for the models package at a path relative to the
test file. That path stopped resolving when the sources moved under
airflow-core, so the check examined no models at all and its assertions
held trivially for an empty set. It has not been able to report a missing
table since, which is how the callback table went unpurged for several
releases.

Walking the package's own search path instead keeps the check working
wherever the sources live, and asserting that models were found stops it
from passing on an empty set again.

With the check restored, partitioned_asset_key_log is the one table it
reports that genuinely has no way to be purged: it carries no foreign
key, so its rows are left behind when the partition Dag run they describe
is cascade-deleted with its dag_run. Only those orphans are deleted --
rows whose partition Dag run still exists are the evidence the scheduler
evaluates to decide when that pending run fires, so they are kept
regardless of age. The other uncovered tables are recorded in the
exclusion list with the reason each is safe.

* Purge orphaned scheduled callbacks while keeping unfired deadlines in db clean

Every callback starts in SCHEDULED, a state outside both the active and the
terminal sets, and an unfired deadline's callback stays there until the deadline
is missed. Deny-listing active states would therefore purge those callbacks and,
through the ON DELETE CASCADE foreign key, silently drop deadlines that have not
fired. The finished states stay allow-listed, so an unknown state keeps its rows.
A SCHEDULED callback is purged only once no deadline references it: deleting a
Dag run cascades away its deadline at the database level, which leaves the
callback behind forever.

* Fix airflow db clean never purging the callback table

The table was renamed from callback_request in Airflow 3.2.0 and the
cleanup configuration was not updated with it. A configured table that
does not exist is skipped with only a warning, so these rows were never
deleted and the table grew without bound, with no way for an operator to
purge it.

Only callbacks that can no longer run are removed. A callback still
awaiting execution owns its deadline row through an ON DELETE CASCADE
foreign key, so deleting one would silently drop a deadline that has not
fired yet.

The sla_miss entry is dropped as well, since that table no longer exists
in Airflow 3.

* Purge orphaned partitioned_asset_key_log rows and restore the db clean coverage check

The check that is meant to catch a metadata table being left out of
airflow db clean looked for the models package at a path relative to the
test file. That path stopped resolving when the sources moved under
airflow-core, so the check examined no models at all and its assertions
held trivially for an empty set. It has not been able to report a missing
table since, which is how the callback table went unpurged for several
releases.

Walking the package's own search path instead keeps the check working
wherever the sources live, and asserting that models were found stops it
from passing on an empty set again.

With the check restored, partitioned_asset_key_log is the one table it
reports that genuinely has no way to be purged: it carries no foreign
key, so its rows are left behind when the partition Dag run they describe
is cascade-deleted with its dag_run. Only those orphans are deleted --
rows whose partition Dag run still exists are the evidence the scheduler
evaluates to decide when that pending run fires, so they are kept
regardless of age. The other uncovered tables are recorded in the
exclusion list with the reason each is safe.

* Purge orphaned scheduled callbacks while keeping unfired deadlines in db clean

Every callback starts in SCHEDULED, a state outside both the active and the
terminal sets, and an unfired deadline's callback stays there until the deadline
is missed. Deny-listing active states would therefore purge those callbacks and,
through the ON DELETE CASCADE foreign key, silently drop deadlines that have not
fired. The finished states stay allow-listed, so an unknown state keeps its rows.
A SCHEDULED callback is purged only once no deadline references it: deleting a
Dag run cascades away its deadline at the database level, which leaves the
callback behind forever.

(cherry picked from commit 478745a)

* Fix airflow db clean never purging the callback table

The table was renamed from callback_request in Airflow 3.2.0 and the
cleanup configuration was not updated with it. A configured table that
does not exist is skipped with only a warning, so these rows were never
deleted and the table grew without bound, with no way for an operator to
purge it.

Only callbacks that can no longer run are removed. A callback still
awaiting execution owns its deadline row through an ON DELETE CASCADE
foreign key, so deleting one would silently drop a deadline that has not
fired yet.

The sla_miss entry is dropped as well, since that table no longer exists
in Airflow 3.

* Purge orphaned partitioned_asset_key_log rows and restore the db clean coverage check

The check that is meant to catch a metadata table being left out of
airflow db clean looked for the models package at a path relative to the
test file. That path stopped resolving when the sources moved under
airflow-core, so the check examined no models at all and its assertions
held trivially for an empty set. It has not been able to report a missing
table since, which is how the callback table went unpurged for several
releases.

Walking the package's own search path instead keeps the check working
wherever the sources live, and asserting that models were found stops it
from passing on an empty set again.

With the check restored, partitioned_asset_key_log is the one table it
reports that genuinely has no way to be purged: it carries no foreign
key, so its rows are left behind when the partition Dag run they describe
is cascade-deleted with its dag_run. Only those orphans are deleted --
rows whose partition Dag run still exists are the evidence the scheduler
evaluates to decide when that pending run fires, so they are kept
regardless of age. The other uncovered tables are recorded in the
exclusion list with the reason each is safe.

* Purge orphaned scheduled callbacks while keeping unfired deadlines in db clean

Every callback starts in SCHEDULED, a state outside both the active and the
terminal sets, and an unfired deadline's callback stays there until the deadline
is missed. Deny-listing active states would therefore purge those callbacks and,
through the ON DELETE CASCADE foreign key, silently drop deadlines that have not
fired. The finished states stay allow-listed, so an unknown state keeps its rows.
A SCHEDULED callback is purged only once no deadline references it: deleting a
Dag run cascades away its deadline at the database level, which leaves the
callback behind forever.