feat(config): honour OTEL_PYTHON_* extensions when OTEL_CONFIG_FILE is set

What

When `OTEL_CONFIG_FILE` is set, `_OTelSDKConfigurator.configure` returns early after calling `configure_sdk(load_config_file(path))`, which means every `OTEL_PYTHON*` implementation extension (e.g. `OTEL_PYTHON_LOGGING_AUTO_INSTRUMENTATION_ENABLED`, `OTEL_PYTHON_TRACER_CONFIGURATOR`) is silently bypassed. These are Python-specific extensions outside the OTel configuration spec, so they have no equivalent in the schema, and ignoring them when a file is present is documented as intentional in #5335 (the current-behaviour decision).

This issue tracks the future-state work to actually honour those extensions alongside the file.

Why

Users migrating from an env-var config to a YAML file expect their existing `OTEL_PYTHON_*` knobs to keep working. Today they silently stop, which is a likely "why doesn't my app behave the same?" support footgun. The spec says the file is authoritative for spec-defined variables only; nothing in the spec prevents an implementation from continuing to honour its own extensions.

Proposed shape

Two layers to design:

1. Behaviour layer: when `OTEL_CONFIG_FILE` is set, after `configure_sdk` returns, run a small `apply_python_extensions()` step that reads each `OTEL_PYTHON*` env var and applies it on top of the global SDK objects that `configure_sdk` produced. Specifically:

   • `OTEL_PYTHON_LOGGING_AUTO_INSTRUMENTATION_ENABLED` → set up the logging handler.
   • `OTEL_PYTHON_{TRACER,METER,LOGGER}_CONFIGURATOR` → load and apply the named configurator to the corresponding global provider.
   • `OTEL_PYTHON_ID_GENERATOR` → maybe; once #5334 lands the schema covers this anyway and the file should win.

2. Schema-extension layer: if we want any of the above to be expressible in the YAML itself, that's a schema extension and should go through the config spec.

Out of scope (for this issue)

• The decision to bypass currently (that is documented under #5335).
• Anything related to spec-defined `OTEL_*` variables: the spec is clear that the file wins.

Related

• #3631 declarative configuration tracking issue
• #5335 the current-behaviour decision (documents the bypass; this issue is the future-state design)

Start by reading _OTelSDKConfigurator._configure and configure_sdk(load_config_file(path)), then review the linked decisions in #5335 and #5334. Define how apply_python_extensions() should apply the listed OTEL_PYTHON* settings after file-based configuration without changing spec-defined precedence; done means the behavior and schema boundary are agreed and covered by tests.