Bug(telemetry): logChatCompression bypasses bufferTelemetryEvent wrapper

### What happened?

logChatCompression() in packages/core/src/telemetry/loggers.ts (line 454) calls logger.emit() and recordChatCompressionMetrics() directly, bypassing the bufferTelemetryEvent() wrapper.
Every other logging function in loggers.ts (~48 functions) wraps its OTel logger.emit() call inside bufferTelemetryEvent(() => { ... }). logChatCompression is the sole exception.
Concrete code evidence:
logChatCompression (line 460-470):
const logger = logs.getLogger(SERVICE_NAME);
logger.emit(logRecord);
recordChatCompressionMetrics(config, { ... });
Compare to logMalformedJsonResponse (line 478, immediately below):
bufferTelemetryEvent(() => {
const logger = logs.getLogger(SERVICE_NAME);
logger.emit(logRecord);
});
The bufferTelemetryEvent function (from sdk.ts) defers telemetry emission until the OTel SDK is fully initialized. Without it, if logChatCompression fires before SDK initialization is complete, the event is emitted against a no-op provider and silently dropped.

### What did you expect to happen?

logChatCompression should wrap its logger.emit() and recordChatCompressionMetrics() calls inside bufferTelemetryEvent() to match the established pattern and ensure the event is buffered until the SDK is ready.
Impact:
- gemini_cli.chat_compression log events may be silently dropped when fired before OTel SDK initialization
- The corresponding metrics data point from recordChatCompressionMetrics is also lost
- Chat compression is a memory management event that fires during heavy sessions when history grows large, meaning it has a higher probability of firing during early session phases when the SDK may not yet be initialized
Fix direction (5 LOC):
Wrap the body of logChatCompression in bufferTelemetryEvent(() => { ... }) following the exact pattern used by all other functions in the file.

### Client information

OS: Windows 11, Node 20.19.0
CLI Version: main branch (HEAD)

### Login information

_No response_

### Anything else we need to know?

Found by auditing the telemetry logging pipeline for consistency. This function was likely added or refactored without the bufferTelemetryEvent wrapper that all other logger functions use. The fix is mechanical: add the wrapper following the existing pattern.