fix: reverting back flushNow lock

Author: astavonin

docs/01-common-patterns/batching-ops.md

@@ -63,8 +63,6 @@ func (b *Batcher[T]) Add(item T) {
 }
 
 func (b *Batcher[T]) flushNow() {
-    b.mu.Lock()
-    defer b.mu.Unlock()
     if len(b.buffer) == 0 {
         return
     }
@@ -73,6 +71,9 @@ func (b *Batcher[T]) flushNow() {
 }
 ```
 
+!!! warning
+    This batcher implementation expects that you will never call `Batcher.Add(...)` from your `flush()` function. We have this limitation because Go mutexes are [**not** recursive](https://stackoverflow.com/questions/14670979/recursive-locking-in-go).
+
 This batcher works with any data type, making it a flexible solution for aggregating logs, metrics, database writes, or other grouped operations. Internally, the buffer acts as a queue that accumulates items until a flush threshold is reached. The use of `sync.Mutex` ensures that `Add()` and `flushNow()` are safe for concurrent access, which is necessary in most real-world systems where multiple goroutines may write to the batcher.
 
 From a performance standpoint, it's true that a lock-free implementation—using atomic operations or concurrent ring buffers—could reduce contention and improve throughput under heavy load. However, such designs are more complex, harder to maintain, and generally not justified unless you're pushing extremely high concurrency or low-latency boundaries. For most practical workloads, the simplicity and safety of a `sync.Mutex`-based design offers a great balance between performance and maintainability.