Fix InMemoryKache::getOrPut race condition in high concurrency

[ryansmartpadpro]

Summary

Fixes #239.

getOrPut had a race condition under high concurrency: a creation deferred could complete and remove itself from creationMap (via its finally block) between the creationMutex.withLock exit and the trailing get(key) call. If the entry was also evicted by concurrent cache pressure in that window, get(key) would find nothing and return null.

The fix captures the deferred inside the lock (before it can remove itself from creationMap) and awaits it directly via getFromCreation(key, deferred), returning the value from the deferred's completion state rather than re-looking it up through the map.

Before:

creationMutex.withLock {
    if (creationMap[key] == null && map[key] == null) {
        @Suppress("DeferredResultUnused")
        internalPutAsync(key, creationFunction)
    }
}
return get(key)  // deferred may have already completed and been evicted

After:

val deferred = creationMutex.withLock {
    if (creationMap[key] == null && map[key] == null) {
        internalPutAsync(key, creationFunction)
    } else {
        creationMap[key]  // capture existing deferred while holding the lock
    }
}
return deferred?.let { getFromCreation(key, it) } ?: get(key)

Test plan

• Added getOrPutHighConcurrency regression test: launches 20,001 coroutines each calling getOrPut with a unique key against a maxSize = 100 cache. The resulting LRU evictions reliably open the race window. The test uses InMemoryKache directly (not testInMemoryKache) so creation deferreds run on Dispatchers.Default real threads — testInMemoryKache overrides creationScope to the single-threaded test dispatcher which hides the race.
• Confirmed the test fails on the unfixed code and passes with the fix.
• Full jvmTest suite passes.

🤖 Generated with Claude Code