fix(telemetry): raise stdout StreamHandlers to WARN when LoggingHandler is installed

[jeanscherf]

Summary

• When both a StreamHandler and an OTel LoggingHandler are active on the root logger at INFO, every log record hits stdout twice: once via the StreamHandler and once via any ConsoleLogExporter in the OTel pipeline
• The filelog receiver on the OTel collector picks up both copies, doubling CLS queue pressure and contributing to collector memory spikes on high-volume workspaces
• After installing the LoggingHandler, raise any existing StreamHandlers on the root logger to WARN so INFO+ flows exclusively via OTLP with full trace correlation
• Stdout still carries warnings and errors for kubectl logs visibility
• FileHandler and other StreamHandler subclasses are not affected (exact type check)
• Also keeps INFO floor on the LoggingHandler itself to prevent DEBUG records reaching production OTLP pipelines regardless of root logger level

Test plan

• TestRaiseStreamHandlersToWarn::test_raises_stream_handler_below_warn — StreamHandler at DEBUG is raised to WARN
• TestRaiseStreamHandlersToWarn::test_does_not_lower_stream_handler_above_warn — StreamHandler already at ERROR is not lowered
• TestRaiseStreamHandlersToWarn::test_ignores_file_handler_subclass — FileHandler is not touched
• TestMakeLoggingHandler::test_handler_level_is_info — LoggingHandler level is INFO
• All 6 tests pass locally: uv run pytest tests/core/unit/telemetry/test_provider.py::TestMakeLoggingHandler tests/core/unit/telemetry/test_provider.py::TestRaiseStreamHandlersToWarn -v

[jeanscherf]

Superseded by a cleaner approach — the INFO floor on the LoggingHandler was wrong as it blocks developer DEBUG logs from reaching CLS. Reopening as a focused fix that only raises stdout StreamHandlers to WARN to prevent duplication.