Modeling - Make fillet solid reconstruction reentrant across threads

[gsdali]

Problem

BRepFilletAPI_MakeFillet is not reentrant: two builds on independent shapes running on separate threads — the concurrency model OCCT documents as supported ("algorithms on different threads in different contexts") — corrupt each other and return a wrong-but-plausible solid that fails BRepCheck. Silent bad geometry: no crash, no thrown error.

The fillet reconstructs its result solid through the legacy TopOpeBRepBuild engine:

ChFi3d_Builder::Compute()
 → TopOpeBRepBuild_HBuilder::MergeSolid()
 → TopOpeBRepBuild_Builder::SplitSolid()   // writes STATIC_SOLIDINDEX

STATIC_SOLIDINDEX (TopOpeBRepBuild_Builder.cxx) is a file-scope static used as a mode flag: SplitSolid sets it to 1/2 to tell FillSolid which operand it is currently splitting, and FillSolid reads it back (if (STATIC_SOLIDINDEX == 1)) to pick the operand shape. Two concurrent reconstructions interleave the writes, so FillSolid reads the wrong value and mis-classifies faces — dropping material.

Evidence (ThreadSanitizer + behaviour)

Isolated pure-C++ repro: fuse three prisms into a U-channel, fillet the seam, 8 threads. Built RelWithDebInfo + -fsanitize=thread, MMGT_OPT=0.

• Stock master: an 8-thread stress returns BRepCheck-invalid solids across several distinct wrong volumes (~15–20% of builds); the correct part is a single volume. TSan reports a data race on STATIC_SOLIDINDEX (write/write in SplitSolid from two threads), plus benign scratch races in the blend solver.
• After this change: 1600 concurrent fillet builds return correct geometry every time (0 invalid, single volume), and the fillet path is TSan-clean.

Change

Converts the fillet-path shared statics to static thread_local — each thread keeps its own copy of the cross-call state, so single-thread behaviour is identical while independent instances on separate threads become reentrant:

File	Variable	Kind
TopOpeBRepBuild_Builder.cxx	STATIC_SOLIDINDEX	Functional — causes the corruption
TopOpeBRep_kpart.cxx	STATIC_lastVPind	Functional — same cross-call-cache pattern ("the vp on which was computed the last CPI")
BlendFunc_ConstRad.cxx, BlendFunc_EvolRad.cxx	ComputeValues scratch	Benign data race (no corruption, but TSan-flagged)
ChFi3d_Builder_6.cxx	checkcurve	Benign data race

This is the same class of fix, in the same engine, as the earlier TKBool thread_local conversion (#1180, 19 globals across 8 files); STATIC_SOLIDINDEX and these were not covered by it.

Reported downstream as SecondMouseAU/OCCTSwift#298.

Draft while I confirm CI; happy to split the benign scratch conversions into a separate change if you'd prefer the functional STATIC_SOLIDINDEX fix on its own.