fix(#341): kernel patch for XCAFDoc_ShapeTool::theAutoNaming race (v1.15.5)

[gsdali]

Summary

Follow-up to #343/v1.15.4. Replaces the bridge-side meshCafMutex() mitigation with the real
kernel fix, matching the #298 PR1→PR2 pattern.

• Auditing every internal caller of theAutoNaming (not just the one originally found) turned up
  two more independent save/modify/restore sites: a separate near-duplicate override in
  RWGltf_CafReader::fillDocument(), and XCAFDoc_Editor::Expand() (which recurses into itself
  while the dance is in flight).
• Verifying the bridge mutex fix under TSan (with the mutex removed, to test the kernel in
  isolation) surfaced a second, narrower problem: an unscoped XCAFDoc_ShapeTool::AddShape call
  still reads the raw bool with no synchronization at all — independent of the "logical"
  interleaving bug.
• Scripts/patches/0011-XCAFDoc_ShapeTool-AutoNamingScope-341.patch: XCAFDoc_ShapeTool::AutoNamingScope
  (new RAII helper, std::recursive_mutex-backed, held for its entire lifetime) replaces all three
  ad hoc call sites; theAutoNaming itself is now std::atomic<bool>.
• Verified via the same TSan stress: 0 races across 4 runs (was 9-17/run pre-fix), zero
  regression on create_fillet_boolean (SheetMetal.Builder.build silently returns an empty solid under parallel test execution (8/10 runs) — contradicts the documented "independent shapes are thread-safe" guarantee #298) / independent-meshing scenarios.
• OCCTBridge_IO.mm's meshCafMutex() (all 12 lock sites + the mutex itself) removed as redundant.
• OCCT.xcframework (all 3 core slices) and OCCTBridge.xcframework rebuilt; Package.swift
  URLs/checksums bumped to v1.15.5 — needs the matching release assets attached.
• Filed upstream as Open-Cascade-SAS/OCCT#1387
  (repro); fix submitted as OCCT#1388 (draft,
  clang-format ✅, non-ASCII check ✅, macOS/Linux/Windows builds ✅, all GTest platforms ✅ as of
  this PR).
• New evidence added to Uncatchable SIGSEGV in parallel swift test run, right after concurrent OBJ imports — possibly related to #341, unconfirmed #344 (the still-uncharacterized SIGSEGV): recurred once more across 12
  post-fix full-suite parallel runs, confirming it's independent of the AutoNaming race this PR
  fixes.

Test plan

• swift build clean (source bridge and OCCTSWIFT_BRIDGE_PREBUILT=1, against the rebuilt
  OCCT.xcframework)
• Issue341MeshCafThreadSafetyTests and the re-enabled StressConcurrencyTests pass
• Full swift test (parallel) × 12 runs post-fix: 9 clean, 2 hit the unrelated pre-existing
  Sweep: ShapeFix/Sewing run outside the caller's progress range in the Robust *Progress import paths (#286 follow-up) #300 timing-flake, 1 hit the unrelated pre-existing Uncatchable SIGSEGV in parallel swift test run, right after concurrent OBJ imports — possibly related to #341, unconfirmed #344 crash — no new failure modes
• TSan stress (pure C++, no bridge) confirms 0 theAutoNaming races with the kernel patch alone

🤖 Generated with Claude Code