GET /api/v2/dags returns empty list after dag-processor restart despite CLI showing DAGs correctly

### Under which category would you file this issue? Airflow Core ### Apache Airflow version main (3.4.0), reproduced via Breeze dev environment ### What happened and how to reproduce it? **Issue Description** After restarting the `dag-processor` process mid-session (e.g. via Breeze's mprocs dashboard, or a container restart), `GET /api/v2/dags` returns an empty list: {"dags":[],"total_entries":0} despite the database containing 203 correctly-parsed DAGs, and `airflow dags list` (CLI) showing all of them without issue. **Root cause (traced)** - All 203 rows in the `dag` table have `is_stale = 1`, even though `last_parsed_time` is recent and matches the actual last dag-processor parse. - The public `GET /api/v2/dags` endpoint applies `exclude_stale=True` by default (`airflow-core/src/airflow/api_fastapi/core_api/routes/public/dags.py`), which silently filters out every DAG. - Passing `exclude_stale=false` explicitly returns the DAGs correctly. - `airflow dags list` (CLI) does not apply the same `is_stale` filter, so it shows everything — creating a CLI vs API discrepancy. - All rows in `dag_bundle` also have `version = NULL`. - Running `airflow dags reserialize` immediately fixes it — `is_stale` flips to `0` for all 203 DAGs. This confirms `update_dags()` (`dag_processing/collection.py:587`, sets `dm.is_stale = False`) works correctly when invoked directly. - However, the live, backgrounded `dag-processor` process, after being restarted, continues parsing DAG files (confirmed via updated `last_parsed_time`) but never clears `is_stale` on its own. - Confirmed `deactivate_stale_dags()` (`dag_processing/manager.py:446`) is NOT the cause — no "Deactivating stale DAG" log lines appear, ruling out DAGs being re-marked stale after being cleared. **Steps to reproduce** 1. `breeze start-airflow --python 3.10` (SQLite backend, default dev setup) 2. Let it fully start, confirm DAGs load in the UI/API normally 3. Restart the `dag-processor` process (e.g. via Breeze's mprocs d…