Make SourceTextData thread-safe with ConcurrentDictionary

[xperiandri]

SourceTextData is shared across concurrent editor operations (classification/tagging and symbol lookup), but its ResizeArray backing store is not thread-safe.

Changes

• Replace ResizeArray<SourceLineData option> with ConcurrentDictionary<int, SourceLineData>.
• Keep SourceTextData.[i] contract as SourceLineData option using TryGetValue in getter.
• Setter stores Some v and removes on None with TryRemove.
• ClearFrom(n) now removes consecutive cached entries using TryRemove and stops on first missing index.
• Add a short note in code explaining concurrent access requirement.

This is the same fix prepared in my fork branch copilot/fix-source-text-data-thread-safety.

[xperiandri]

Fixes #20112

[T-Gro]

🤖 This review was generated by AI (@expert-reviewer agent). Findings may contain inaccuracies — please verify independently.

Summary: Correct, well-scoped fix. Swapping the ResizeArray<SourceLineData option> for a ConcurrentDictionary<int, SourceLineData> removes the real memory-corruption hazard (concurrent extendTo/Add on a non-thread-safe list), and it also removes the unsafe side-effect where the getter previously mutated the backing store. ClearFrom and the setter stay behaviorally equivalent to the old code, since a missing key is indistinguishable from the previous None/uncached slot, and the clear loop still terminates at the first gap. Imports (System.Collections.Concurrent) and the (concurrencyLevel, capacity) constructor arguments are correct. No correctness, security, or performance regressions found.

[T-Gro]

Non-blocking observation: ConcurrentDictionary makes each individual entry access atomic, which fixes the memory-safety bug. However, the multi-line read-modify-write sequence in getFromRefreshedTokenCache (read [i] -> scanSourceLine -> set [i], chaining lexState, then ClearFrom(endLine+1)) is still not atomic as a whole. Two concurrent scans over overlapping line ranges on the same SourceTextData can interleave and briefly cache an inconsistent lex-state chain. This is a strict improvement over the old code (which could corrupt the list), and it self-heals on the next read via the IsValid/LexStateAtStartOfLine checks, so it is almost certainly acceptable. Worth noting only that the guarantee is container-level, not sequence-level, so the must be thread-safe comment does not imply a coherent snapshot across lines.