Fix crash: ConcurrentQueue mutates without a barrier

[Kevin-4Spaces]

The crash

Swift/Array.swift:1845: Fatal error: Array replace: subrange extends past the end

reached from AptabaseClient timer flush → EventDispatcher.flush() → ConcurrentQueue.dequeue(count:).

Cause

ConcurrentQueue's queue is created with attributes: .concurrent, so a plain sync grants shared access — it does not serialize. enqueue(_:) and enqueue(contentsOf:) correctly use async(flags: .barrier), but dequeue() and dequeue(count:) mutate elements inside a plain sync:

queue.sync {
    for _ in 0 ..< min(count, self.elements.count) {
        dequeuedElements.append(self.elements.removeFirst())
    }
}

Two concurrent callers each evaluate self.elements.count, then both removeFirst(), and the second removes past the end.

This is reachable in normal use: flush() runs from the repeating timer and from app lifecycle handlers, so two flushes can overlap on a real device.

Fix

Give both dequeues sync(flags: .barrier). isEmpty and count keep the plain sync — concurrent reads are the reason for the concurrent queue.

Tests

Two regression tests drain a 2,000-element queue from 8 concurrent workers and assert every element is dequeued exactly once, covering both dequeue() and dequeue(count:).

Against the unpatched implementation both crash:

error: Exited with unexpected signal code 11

With the barrier, the full suite passes (11 tests, 0 failures).