Three config.yml options are never read: color_log_error_keywords, color_log_warning_keywords, ignore_first_depends_on_past_by_default

### Apache Airflow version

`main` at `299ca2c85` (also present in 3.2.x).

### What happened?

Three options in `airflow-core/src/airflow/config_templates/config.yml` are never read. Their names do not appear anywhere else in the repository — not in Python, not in the React UI, not in the Helm chart, not in the docs.

| config.yml | option | added | references outside config.yml |
|---|---|---|---|
| `:1140` | `[logging] color_log_error_keywords` | 2.10.0 | **0** |
| `:1148` | `[logging] color_log_warning_keywords` | 2.10.0 | **0** |
| `:2737` | `[scheduler] ignore_first_depends_on_past_by_default` | 2.3.0 | **0** |

None of the three carries `version_deprecated` or `deprecation_reason`, so they are presented as current settings: `config.yml` drives both the generated `airflow.cfg` and the [configuration reference](https://airflow.apache.org/docs/apache-airflow/stable/configurations-ref.html). Someone reading the docs sets one of these and nothing happens, with no warning.

The two `color_log_*_keywords` entries say the keywords "should display the line in red color in UI". Nothing reads them, and `error_keywords` / `warning_keywords` appear nowhere else either — including the 597 `.tsx` files under `airflow-core/src/airflow/ui`, so it is not a case of the UI having taken the setting over under a camelCase name.

`ignore_first_depends_on_past_by_default` is the one I would most like a second opinion on, because it is a scheduling setting rather than a cosmetic one and its description promises real behaviour ("first task instance of a task ignore depends_on_past setting").

I could not check *when* each stopped being read — my clone is shallow. If that matters I am happy to look again with full history.

### What you think should happen instead?

Whichever you prefer — the project already has both patterns:

* mark them with `version_deprecated` / `deprecation_reason`, the way `[traces] otel_debug_traces_on` is marked ("This parameter is no longer used"), so they stay listed but honestly; or
* remove the entries.

I did not want to pick, since removing a listed option is a compatibility decision and the deprecation path is yours.

### How to reproduce

```console
$ grep -rI -w color_log_error_keywords . | grep -v config_templates/config.yml | wc -l
0
$ grep -rI -w color_log_warning_keywords . | grep -v config_templates/config.yml | wc -l
0
$ grep -rI -w ignore_first_depends_on_past_by_default . | grep -v config_templates/config.yml | wc -l
0
```

`grep -rI` covers every text file in the tree, not just Python.

### Anything else?

**How this was found, and what I ruled out.** I parsed every option out of `config.yml` (323 options across 25 sections) and compared it against every place the code names a section and an option together (509 distinct pairs).

The raw comparison flagged 49 options. All but three were false positives, and the reasons are worth stating so nobody repeats them:

* **Keyword form.** `conf.getboolean(section="secrets", key="use_cache", fallback=False)` — the two strings are not adjacent.
* **Factory helpers.** `_config_int_factory("dag_processor", "parsing_processes")` and `_config_bool_factory("scheduler", "catchup_by_default")` never mention `conf`.
* **Aliased import.** `airflow_conf.getboolean("core", "dags_are_paused_at_creation")` in `models/dag.py`.
* **Whole-section reads.** `conf.getsection("sentry")` and `conf.getsection(section, team_name=...)` in `BaseExecutor` pull every option in `[sentry]` and `[api]` at once.
* **Indirection through a dict.** `sql_alchemy_connect_args_async` is live but reached via `{"async": "sql_alchemy_connect_args_async"}` in `settings.py:354`, so its name is never next to `"database"`.
* **My own reading error.** I first looked for `is_deprecated: true` and found none, which made `[traces] otel_debugging_on` and `[traces] otel_debug_traces_on` look dead. `config.yml` marks retirement with `version_deprecated` / `deprecation_reason`, and both of those are already marked. They are not part of this report.

Only the three above survived, and each was then checked with a whole-repository search across all file types rather than trusting the comparison.

### Are you willing to submit PR?

- [X] Yes I am willing to submit a PR — happy to do either the deprecation markers or the removals, once you say which.

### Gen AI usage

AI-assisted (Claude Code, Opus 5). The comparison script and this report were produced with the tool. I verified the findings myself before filing: I confirmed each of the three names has zero occurrences outside `config.yml` across every file type including the TypeScript UI, read `settings.py` to see how `sql_alchemy_connect_args_async` is actually reached, read the `[metrics]` and `[traces]` blocks to find the `version_deprecated` markers I had initially missed, and went through each false-positive class above one at a time instead of reporting the script's raw output. I understand the finding and take responsibility for it.

### 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 in airflow-core/src/airflow/config_templates/config.yml at the [logging] and [scheduler] entries, then verify the three names have no repository references using the issue's grep searches. Compare the existing version_deprecated and deprecation_reason pattern in the [traces] block. Done means the options are either removed or explicitly marked as no longer used, according to the maintainer's compatibility decision.

Written by the indexing model from the issue text.