Lock the shared sets of the parallel STEP import

[dsn27]

Fixes an intermittent failure of StepCyclicReferenceTest.import_step_with_representations_that_map_each_other, a test from #498. The test failed now and then on the 2-core CI runner, on #468 and #472 so far:

System.NullReferenceException: Object reference not set to an instance of an object.
   at CADability.ImportStep.Read(String filename) in /_/CADability/ImportStep.cs:line 1683

Cause

With StepImport.Parallel, CreateEntity runs on several threads. Two places in it added to a shared HashSet<Item> without a lock:

• mappedItems.Add(item) for every MAPPED_ITEM;
• products.Add(relatingProduct) for assemblies. The other place that adds products already uses lock (products).

Concurrent Add calls can corrupt a HashSet. When Read later enumerates mappedItems (line 1683), it meets a null entry. The bug is older than #498. The new test makes it visible, because it imports a file with mapped items 20 times in parallel.

Fix

Both Add calls now run under a lock on their set, as the existing lock (products) does.

Verification

I limited the test process to 2 cores with taskset -c 0,1, as on the runner:

	runs	failed
without the fix	30	3
with the fix	60	0

CADability.ImportTests on Linux: 85 passed, 5 skipped, 0 failed.

Not covered here

The assembly branch of the parallel import changes other shared state without a lock: the parameter dictionary of a product ("_children") and the list of its children. That is a separate, pre-existing issue, and no test shows it, so this PR leaves it as it is.

---

Generated by Claude Code