Fix RealMutableStore write-queue data race (inverted lock polarity)

Summary

RealMutableStore's per-key write-request queue is a non-thread-safe ArrayDeque
(internal/definition/WriteRequestQueue.kt), but the lock guarding it has inverted polarity:
the mutators take a shared lock while the only exclusive holder is a pure read. Concurrent
writes to the same key therefore mutate the deque while another coroutine iterates it, corrupting
the backing array.

• JVM: the deque's fail-fast iterator throws ConcurrentModificationException, which
  RealMutableStore catches and surfaces as StoreWriteResponse.Error.Exception.
• Kotlin/Native: the racing structural add reallocates the backing array under an active
  iteration → freed-pointer dereference → EXC_BAD_ACCESS (a hard process crash).

This reproduces in production on a multithreaded native dispatcher under sustained same-key writes
(~every few seconds across concurrent streams).

Root cause

withWriteRequestQueueLock guards the queue with a Lightswitch — a shared/reader lock that lets
multiple holders run concurrently:

threadSafety.writeRequests.lightswitch.lock(threadSafety.writeRequests.mutex)
try {
    getQueue(key).block()
} finally {
    threadSafety.writeRequests.lightswitch.unlock(threadSafety.writeRequests.mutex)
}

All mutating access flows through this method:

• addWriteRequestToQueue → queue.add(writeRequest)
• updateWriteRequestQueue → for (writeRequest in this) { ... } (iterate + rebuild)

Because both take the shared lightswitch, they do not exclude each other. The only operation
taking the exclusive writeRequests.mutex is getLatestWriteRequest → queue.last(), a pure
read. The polarity is backwards: the mutators share, the reader is exclusive.

Fix

Guard all write-queue access with the per-key exclusive mutex, so add / iterate / rebuild
mutually exclude each other (and exclude getLatestWriteRequest, which already uses
writeRequests.mutex):

return threadSafety.writeRequests.mutex.withLock {
    val queue = getQueue(key)
    queue.block()
}

Regression test

MutableStoreConcurrencyTest (commonTest) fires 64 concurrent writes to the same key over 50
rounds on Dispatchers.Default, plus a sequential baseline. It asserts no corruption-class error
(ConcurrentModificationException / NullPointerException / IndexOutOfBoundsException); on Native,
reaching the assertion at all proves the process didn't crash.

Verified:

• JVM (:store:jvmTest): RED pre-fix (NullPointerException, 64/64 in round 0) → GREEN post-fix.
• Native (:store:iosSimulatorArm64Test): RED pre-fix (kotlin.ConcurrentModificationException,
  round 19) → GREEN post-fix.
• Full JVM suite: 101 tests, 0 failures (no regression).

Note: concurrent writes to the same key can still legitimately fail with
IllegalArgumentException("No writes found ...") — a separate, pre-existing logical race where
one write drains another's queue entry. That is not memory corruption and is out of scope here; the
test tolerates it and documents it inline.

Notes for reviewers

• Lightswitch removed (2nd commit). Once withWriteRequestQueueLock stopped using it, nothing
  acquired it anywhere — readCompletions already locked via its own mutex, so the lightswitch
  field on StoreThreadSafety was read by nothing. The 2nd commit drops the field and deletes the
  class. Lightswitch/StoreThreadSafety/ThreadSafety are all internal and absent from the
  binary-compatibility-validator dumps, so this changes no public API/ABI — jvmApiCheck and
  klibApiCheck both pass unchanged. (Happy to split this into a follow-up PR if you'd prefer the
  fix land in isolation.)
• Re-entrancy: kotlinx.coroutines Mutex is non-reentrant. The call graph has no nested
  acquisition of the same writeRequests.mutex (getLatestWriteRequest unlocks in finally before
  tryUpdateServer → updateWriteRequestQueue; addWriteRequestToQueue runs in onEach before the
  collect block), so this is safe. One caveat worth a maintainer's eye: updateWriteRequestQueue
  invokes user onCompletion(s) callbacks while holding the queue lock — a callback that re-enters
  the same key's write path would now deadlock instead of (unsafely) racing. Re-entrant store writes
  from a completion callback are an unusual pattern, but flagging it explicitly.

Base

Branched off main (5.1.0-alpha08). The same methods exist unchanged back through 5.1.0-alpha06,
so the fix backports cleanly.