Per-key secrets-backend config options are not recognised as sensitive under a team-scoped spelling

### What happened

`airflow/api_fastapi/core_api/services/public/config.py` treats the synthetic per-key secrets-backend options as sensitive by matching **literal** section names:

```python
_PER_KEY_SENSITIVE_PREFIXES: dict[str, str] = {
"secrets": "backend_kwarg__",
"workers": "secrets_backend_kwarg__",
}
```

Both `_is_per_key_sensitive_option` and `_mask_per_key_sensitive_options` key off those exact names, so neither recognises a team-scoped spelling of the same option:

- the config-file section `[=secrets]`, and
- `AIRFLOW_____SECRETS__BACKEND_KWARG__*`, which is reported under a section named after the *team* rather than after `secrets`.

This is the same root cause as apache/airflow#70755 — sensitivity being decided from a section name that a team-scoped override does not use — but a different mechanism, and it was left untouched there.

### Why it is not currently exploitable

`_get_custom_secret_backend` is not team-aware, so there is no way to configure a team-scoped `backend_kwarg__*` that the literal-section match could miss. Nothing leaks today. The gap becomes live the moment secrets backends gain team scoping, and at that point it fails open — a team's backend credentials would be returned in full by `GET /config`.

### What needs doing

Resolve both spellings back to the base option before deciding sensitivity, as `AirflowConfigParser.is_sensitive_option` now does for registered options. The env-var spelling is the awkward half: it lands under a section named after the team, which is the shape `_names_sensitive_team_env_var` deals with in the shared parser. The synthetic per-key options are built separately and need their own pass over `conf_dict`.

### Acceptance criteria

- A team-scoped `backend_kwarg__*` / `secrets_backend_kwarg__*` value is redacted by `GET /config` and `GET /config/section/{section}/option/{option}` when `display_sensitive=False`, under both the `[=secrets]` and the `AIRFLOW_____SECRETS__...` spelling.
- `display_sensitive=True` still returns real values.
- Tests covering both spellings.

Raised in review of apache/airflow#70755.

---
Drafted-by: Claude Code (Opus 5); reviewed by @potiuk before posting

Start in airflow/api_fastapi/core_api/services/public/config.py, then compare AirflowConfigParser.is_sensitive_option with _names_sensitive_team_env_var and the _is_per_key_sensitive_option and _mask_per_key_sensitive_options paths. Add tests for both team-scoped spellings and verify both GET /config endpoints redact values when display_sensitive=false while preserving real values when it is true.

Written by the indexing model from the issue text.