Make UniqueTimestampFactory thread-safe using lock-free atomic operations

[konard]

Summary

• Fixed race condition in UniqueTimestampFactory.Create() method that could produce duplicate timestamps in multi-threaded environments
• Implemented thread-safe solution using Interlocked.CompareExchange with retry loop for optimal performance
• Added comprehensive test suite to validate thread-safety and timestamp uniqueness

Technical Details

The original implementation had a race condition at UniqueTimestampFactory.cs:23:

_lastTicks = utcTicks > _lastTicks ? utcTicks : _lastTicks + 1;

Multiple threads could read the same _lastTicks value simultaneously, leading to duplicate timestamps.

The solution uses lock-free atomic operations:

ulong lastTicks, newTicks;
do
{
    lastTicks = _lastTicks;
    newTicks = utcTicks > lastTicks ? utcTicks : lastTicks + 1;
}
while (Interlocked.CompareExchange(ref _lastTicks, newTicks, lastTicks) != lastTicks);

Test Coverage

Added 3 new comprehensive tests:

• ThreadSafetyTest: Validates uniqueness across 5,000 concurrent timestamps (50 tasks × 100 timestamps)
• SequentialOrderTest: Ensures timestamps maintain ascending order in single-threaded execution
• ConcurrentSequentialOrderTest: Verifies ordering within concurrent execution scenarios

All tests pass, confirming the thread-safety implementation works correctly.

Performance Impact

• Lock-free implementation provides better performance than mutex-based approaches
• Uses CPU-level atomic operations for minimal overhead
• Maintains the [MethodImpl(MethodImplOptions.AggressiveInlining)] optimization

🤖 Generated with Claude Code

---

Resolves #41