Fix ConcurrentModificationException in transcript handling (#102)

[xiajon]

Issue

Fixes #102 — ConcurrentModificationException in ChatServiceImpl.handleTranscriptItemUpdate.

Root cause

transcriptDict (a LinkedHashMap) and internalTranscript (an ArrayList) are read and mutated from three threads with no synchronization:

• Main dispatcher — the service's own coroutines (handleTranscriptItemUpdate iterates internalTranscript via indexOfFirst).
• Timer thread — removeTypingIndicators calls removeIf on both collections when the typing indicator expires.
• Dispatchers.IO — every ChatSession suspend method (sendMessage, getTranscript, resendFailedMessage, …) runs its ChatService call on IO.

A structural modification on one thread invalidates an in-flight iteration on another → ConcurrentModificationException.

Why the fix touches more than the reported function

The stack trace in #102 points at handleTranscriptItemUpdate, but that is only where the crash surfaced. I verified empirically that guarding that one function just relocates the crash: with only handleTranscriptItemUpdate synchronized, the regression test then throws at getRecentDisplayName; guarding that too, it throws in removeTypingIndicators. A lock only works if every accessor takes it.

The fix

• A single reentrant monitor (transcriptLock) guards all access to the shared collections.
• Snapshots are taken under the lock and handed to subscribers; the lock is never held across a coroutine suspension point.
• Compound read-modify-write sequences (e.g. indexOfFirst-then-insert) run inside one locked region.

A concurrent collection (ConcurrentHashMap / CopyOnWriteArrayList) is not sufficient here: it makes each individual operation thread-safe but does not make the compound index-then-mutate atomic. I confirmed this — swapping in concurrent collections makes the CME disappear but surfaces an ArrayIndexOutOfBoundsException and duplicate items instead.

The change is deliberately mechanical: existing control flow is preserved and each hunk wraps existing statements in synchronized(transcriptLock) { … }. No message-handling logic was altered.

Testing

• New regression test test_concurrentTranscriptUpdates_doNotThrowConcurrentModificationException drives the transcript from 8 threads; it fails with ConcurrentModificationException on main and passes with this change.
• Full suite: 188/188 passing (./gradlew :chat-sdk:testDebugUnitTest --rerun-tasks).

Follow-ups (not in this PR)

• The lock guards the containers, not the mutable Message/MessageMetadata items handed to subscribers; per-item field mutation while the UI reads the same instance is a separate concern.
• Encapsulating the collections behind a small TranscriptStore type would make "hold the lock" structurally enforced rather than a convention.