[SDK] BatchLogRecordProcessor still drains the queue in a tight loop, inconsistent with BatchSpanProcessor fix

Describe your environment

• Platform: macOS
• opentelemetry-cpp version: main branch
• Component: sdk/src/logs/batch_log_record_processor.cc
• BatchLogRecordProcessor configuration:
  • max_queue_size = 8192
  • max_export_batch_size = 2048
  • schedule_delay_millis = 5000

Steps to reproduce

1. Configure BatchLogRecordProcessor with a LogRecordExporter that counts export calls and records per call.
2. Produce log records at a constant rate (e.g. 5,000 logs/s) for 10 seconds.
3. Observe the number of export requests and the average number of logs per request.
4. Produce 50,000 log records without calling ForceFlush().

What is the expected behavior?

With max_export_batch_size = 2048, exports should be close to 2048 records each. After #4466, BatchSpanProcessor behaves this way: on a normal wakeup it exports at most one batch, and only ForceFlush() / Shutdown() drain the entire buffer.

BatchLogRecordProcessor should follow the same semantics.

What is the actual behavior?

BatchLogRecordProcessor::Export() still drains the whole buffer in a tight loop:

void BatchLogRecordProcessor::Export()
{
  do {
    bool notify_force_flush =
        synchronization_data_->is_force_flush_pending.exchange(false, std::memory_order_acq_rel);
    if (notify_force_flush) {
      num_records_to_export = buffer_.size();
    } else {
      num_records_to_export =
          buffer_.size() >= max_export_batch_size_ ? max_export_batch_size_ : buffer_.size();
    }
    // ... consume & export ...
  } while (true);
}

And the worker wakes up as soon as the buffer is non-empty:

synchronization_data_->cv.wait_for(lk, timeout, [this] {
  ...
  return !buffer_.empty();
});

Measured result

The first export is 2048 records; every subsequent export in the same wakeup is ~20–25 records because the worker keeps draining the buffer instead of waiting for the next full batch.

Additional context

• #4449 reported the same problem for BatchSpanProcessor.
• #4466 fixed the trace path by changing the worker wait predicate and making Export() drain the buffer only for ForceFlush() / Shutdown().
• The logs path (sdk/src/logs/batch_log_record_processor.cc) still uses the old implementation and should be aligned with the trace path.

Start with sdk/src/logs/batch_log_record_processor.cc and compare its behavior with the BatchSpanProcessor changes from #4466. Reproduce the export-call and batch-size measurements described in the issue, then verify that normal wakeups export one batch while ForceFlush() and Shutdown() drain the buffer.