Fix #4727: release the message-batch semaphore on the double-checked-lock fast path (composite rebuild deadlock)

[erdtsieck]

Fixes #4727 (and the residual deadlock behind the closed #4721).

Problem

ProjectionUpdateBatch.CurrentMessageBatch leaks its SemaphoreSlim. After await _semaphore.WaitAsync(...), the inner double-checked if (_batch != null) return _batch; sits outside the try/finally, so the second concurrent caller to acquire the semaphore returns without ever calling _semaphore.Release().

During an optimized composite rebuild whose stage emits side-effect messages, the parallel event slices all call CurrentMessageBatch via ProjectionBatch.PublishMessageAsync. They queue on the semaphore; the first creates the batch and releases; the second hits the inner early-return and leaks the semaphore — so every remaining queued slice is parked on WaitAsync forever and the rebuild freezes (idle, no error, no DB query). Captured via a managed dump in #4727.

Fix

Move the inner null-check inside the try so finally always releases the semaphore, and drop the Task.Delay(Random.Shared.Next(25, 200)) band-aid that was only masking the race.

Test

DaemonTests/Bugs/Bug_4727_message_batch_semaphore_leak.cs — a gated IMessageOutbox holds the semaphore while the first batch is created so N concurrent CurrentMessageBatch callers reliably pile up on it. The test deadlocks (15s timeout) on the previous code and passes in ~1s with this fix; all callers observe the single shared batch.

Found in production on a sharded + tenant-partitioned store (Marten 9.7.3 / JasperFx 2.9.9 / Wolverine 6.8.0): an invoices composite rebuild whose stage-2 members publish side-effect messages froze at a batch boundary on every deploy.