Parallel arch: add a ThreadSanitizer CI job to dynamically prove data-race freedom

The zero-lock architecture (#197) claims data-race freedom by design. Today that is guarded
statically (the CI lock lint that rejects Mutex/RwLock/OnceLock/… in src/) and by
determinism tests (order + cross-thread-count, pipeline.rs; 64-thread isolation,
architecture_test.rs). Those are strong but infer race freedom.

The gold-standard dynamic check is ThreadSanitizer: build + run the parallel pipeline tests
under -Zsanitizer=thread (nightly, with a sanitizer-instrumented std via -Zbuild-std), which
flags any actual data race at runtime.

Scope:

• A CI job (nightly toolchain) running the parallel tests (compile_pipeline*,
  concurrent_compilations_have_isolated_topologies, the determinism tests) under TSan.
• A stress iteration count so rare races surface.
• Document how to run it locally.

Deferred as CI infrastructure; noted in docs/parallel_compiler_architecture.md §9.5.

Start with docs/parallel_compiler_architecture.md §9.5, then inspect the existing CI configuration and the parallel test entry points named in the issue: pipeline.rs and architecture_test.rs. The job should use a nightly toolchain with ThreadSanitizer and run the listed tests repeatedly; done also includes local-run documentation and no reported races.