FileLogger2: drain the transition queue in the destructor after joining the writer thread

[simobenziane]

FileLogger2::writerLoop() checks loop between batches, and ~FileLogger2() sets loop = false and joins without draining transitions_queue. A transition pushed after the writer's last swap — typically the root's RUNNING→IDLE from a haltTree() issued right before the logger is destroyed — is lost, so the .btlog ends mid-flight. Reproduced with a serve loop that halts the tree on a broken pipe and then resets its logger; under load the last IDLE is missing in a fraction of runs (12 of 300 with the destructor instrumented, every failure with a non-empty queue at the join).

This PR extracts the batch write into writeBatch(), adds drainQueue() (swap under the mutex, then write), and calls it in the destructor after the join, before the file is closed. No behaviour change for callers. A looping gtest (LoggerTest.FileLogger2_DrainsQueueAfterHaltThenImmediateDestroy, 300 iterations) ticks a small tree to RUNNING, halts it, destroys the logger at once and asserts the root's last transition in the file is IDLE — it fails on the unpatched code under CPU load and passes with the patch.

🤖 Generated with Claude Code

[simobenziane]

CI note: the one red check, coverage, fails on Decorator.DestroyTreeWhileTimerIsPending (an abort in timer_queue.h:209, TimerQueue::run()), which this PR does not touch; the new LoggerTest.FileLogger2_DrainsQueueAfterHaltThenImmediateDestroy passed in that same job and every other check is green. Happy to rebase if that test is fixed on master.