CompiledSystem and CompiledHomotopy global caches are unsafe under concurrent construction

[orebas]

CompiledSystem and CompiledHomotopy intern normalized symbolic objects in
process-global Dict tables. Their lookup, collision scan, insertion, and
type-level interpret reads are currently unsynchronized.

Concurrent construction can therefore race on both the dictionaries and their
stored vectors. Reads also need protection because an insertion can rehash a
dictionary while interpret(::Type) is accessing it.

Evidence

In a concurrent CompiledSystem stress test, each completed run constructed
720,000 distinct systems. The cache retained only 718,239, 717,437, 717,804,
and 699,567 entries in four runs, directly demonstrating lost or corrupted
TSYSTEM_TABLE updates.

THOMOTOPY_TABLE has the same unsynchronized access pattern, but I have not
separately reproduced corruption in that table.

One easy-to-miss detail: interpret(compiled_system) returns the instance's
original system and does not read the cache. The cache-reading check is
interpret(typeof(compiled_system)).

Expected behavior

Constructing compiled systems or homotopies concurrently should not lose cache
entries or race with generated evaluator lookup.

[orebas]

Hello. In case it is not obvious, the issues 717 718 and 720 (and the corresponding PRs) which were filed under my name, were all created by ChatGPT-5.6 sol and corroborated by either Fable or Opus.

This one is the most serious, and also the hardest to review. I'm pretty sure I understand the issue: when many concurrent threads created by a user call solve() a lot, there's a a global table with no lock or mutex which can cause problems. The code in the PR looks relatively innocent to me, however I have had experiences where introducing locks can cause unexpected deadlocks and other problems. Please let me know if I can help in any way. Thanks.