Bring back a DB‑independent way to validate/inspect DAGs from the CLI

### Apache Airflow version

3.1.0

### If "Other Airflow 2/3 version" selected, which one?

_No response_

### What happened?

In Airflow 3, commands like airflow dags list and airflow dags list-import-errors rely on the metadata database being populated by a running DAG processor (scheduler/standalone). This removes a lightweight, DB‑independent way to validate DAG parse/import errors and enumerate DAGs directly from the filesystem, which used to be possible in pre‑3.x workflows (e.g., via CLI parsing of DAG_FOLDER without a running processor).
Ask: Provide a supported, DB‑independent CLI path to validate and list DAGs/import errors - suitable for local development, pre‑commit hooks, and CI - without requiring the scheduler, processors, or airflow standalone.

I initially reported this as #49330 . Now that there is larger consensus that this change was un-intentional. lets bring it back! 😄

cc: @kaxil

### What you think should happen instead?

_No response_

### How to reproduce

Seed a basic dag in the dags directory and run. Just use the defaults.
```
airflow db migrate
airflow dags list
```

### Operating System

Ubuntu

### Versions of Apache Airflow Providers

_No response_

### Deployment

Docker-Compose

### Deployment details

_No response_

### Anything else?

_No response_

### Are you willing to submit PR?

- [x] 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)

Start with the airflow dags list and airflow dags list-import-errors CLI entry points, reproducing the behavior with a DAG in DAG_FOLDER after only airflow db migrate. Trace where these commands require metadata populated by a DAG processor. Done means a supported CLI path can list DAGs and report parse/import errors from the filesystem without a scheduler, processor, or standalone deployment.

Written by the indexing model from the issue text.