thalarch-jvm-concurrencylisted

# Thalarch JVM Concurrency Concurrency changes are correctness changes first and performance changes second. Do not prescribe a concurrency primitive until the repository's actual JDK, framework, execution model, and ownership boundaries are known. ## 1. Establish the execution model Before editing, identify: - configured JDK/runtime version; - platform threads, virtual threads, executor pools, ForkJoin/common pool, framework-managed executors, reactive/event-loop execution, or mixed model; - task owner and task lifetime; - mutable shared state; - cancellation/interruption contract; - request/security/context propagation; - blocking vs CPU-bound work; - shutdown/resource ownership. Verify preview/incubator/final API status against the actual JDK and current primary documentation. Never copy a virtual-thread/structured-concurrency/ScopedValue example from another Java version without checking the project version. ## 2. Safety invariants For each shared state transition answer: - Who can read it? - Who can write it? - What makes the operation atomic? - What establishes visibility/happens-before? - Can callbacks or external code execute while a lock is held? - What ordering constraints exist between locks/resources? - What happens when the operation runs twice, concurrently, partially, or is cancelled? Prefer immutable ownership or message-passing/isolated state when it naturally fits the existing architecture. Do not replace a clear synchronized design with a more e