[BUG] BatchLogRecordProcessor: lost condvar wakeup can stall Shutdown/ForceFlush by up to one schedule_delay

[denizariyan]

Describe your environment

• Platform: macOS 26.5.2, Darwin Kernel Version 25.5.0, arm64
• Build system: Bazel
• opentelemetry-cpp: current main (3a228da6), same pattern present in release 1.27.0

Description

Follow-up to #4373 / #4382, which fixed the lost-wakeup pattern in BatchSpanProcessor
only. BatchLogRecordProcessor has the identical pattern: cv.notify_all() /
force_flush_cv.notify_all() are issued without holding the mutex that guards the
waiter's predicate, leaving a lost-wakeup window. If the waiter has evaluated its
wait_for predicate as false but has not parked yet, the notification is missed and it
only wakes on the next schedule_delay.

A missed wakeup causes a stall of up to one schedule_delay, which is quite unexpected for
Shutdown() and ForceFlush(). Especially with a longer configured schedule delay, a Shutdown()
at process exit can block for that whole period.

The metric equivalent (PeriodicExportingMetricReader shutdown) is already covered by
#4365, so this issue is scoped to the log processor.

Steps to reproduce

Same shape as #4373: set schedule_delay to something large (e.g. 10 min) so that a lost
wakeup is unmistakable rather than a CI hiccup, hammer ForceFlush() / Shutdown()
concurrently with log emission, and use a watchdog with a reasonable timeout to catch the stall.

A stress test mirroring the pattern in #4382 could be used as a regression test.

What is the expected behavior?

• Shutdown() and ForceFlush() return promptly, regardless of the exact interleaving
  between the notify and the waiter parking.
• The log stress test passes all runs.

What is the actual behavior?

The wakeup can be missed leading to the operation stalling up to one schedule_delay.