fix(#344): kernel + bridge fixes for the SIGSEGV that survived #341 (v1.15.6)

[gsdali]

Summary

Root-causes and fixes #344 (the SIGSEGV that survived #341's theAutoNaming fix), independently of that earlier work — a genuinely different pair of races, both in code the #341 TSan stress never reached (that harness bypasses XCAFApp_Application/CDF_Application entirely; the real bridge path doesn't).

1. XCAFApp_Application::GetApplication()'s lazy singleton init races two threads' first concurrent call. Confirmed via a debug build + custom SIGSEGV handler (~50% crash rate at 10 threads × 3000 barrier-synchronized rounds) and via TSan (234 race reports, the majority a destructor cascade from concurrently-constructed duplicate instances).
2. CDF_Directory::Add/Remove/Contains mutate a shared document list with zero synchronization.

Found during validation: fixing #1 means every caller genuinely shares ONE TDocStd_Application instance for the first time, surfacing two more races on that instance's other state (previously masked by threads sometimes getting different, uncontended instances):

3. TDocStd_Application::Resources() — identical lazy-init bug.
4. Resource_Manager's internal maps and CDF_Application::myReaders/myWriters — zero synchronization.

All four fixed in the kernel patch (Scripts/patches/0012). 0/12 further swift test runs of OCCTXCAFTests reproduce any of them.

A fifth, architecturally different crash also surfaced (BinLDrivers_DocumentStorageDriver::Write corrupting a shared, cached, non-reentrant storage-driver instance under concurrent Save/SaveAs of the same format — ~60% crash rate once the races above stopped masking it). Filed separately as #349 since it needs its own kernel investigation (a shared worker object, not a container needing a lock). Ships with an interim bridge-side mutex (ocafStoreMutex()) serializing the three OCAF save/load bridge calls, matching the #298/#341 PR1→PR2 pattern.

Test plan

• swift build — zero errors
• swift test --filter OCCTStressTests — 354/354 pass, including new parallelDocumentCreate regression test
• swift test --filter OBJDocumentIOTests — 4/4 pass
• swift test --filter OCCTXCAFTests — 0/12 crashes with the full fix + bridge mitigation in place (was crashing in the original Uncatchable SIGSEGV in parallel swift test run, right after concurrent OBJ imports — possibly related to #341, unconfirmed #344 report, and again mid-validation before the bridge mitigation)
• Kernel patch validated via a debug build + custom SIGSEGV/SIGBUS handler, and via ThreadSanitizer (minimal-module protocol matching 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/isSelfIntersecting: hard-bounded (worker-thread) variant + upstream OCCT checkpoint/quadratic report (follow-up to #293) #319/NCollection race under parallel execution: documented downstream as 'run --no-parallel', never filed or characterised upstream — needs the #298 TSan protocol #341)
• Filed upstream: Open-Cascade-SAS/OCCT#1389 (repro) / OCCT#1390 (fix) — CI green (macOS/Ubuntu/Windows builds, GTest, regression tests)
• Docs updated: CLAUDE.md, docs/CHANGELOG.md, docs/thread-safety.md, Scripts/patches/README.md, okf/references/carried-occt-patches.md
• OCCT.xcframework + OCCTBridge.xcframework rebuilt (all 3 core slices), Package.swift version/checksums bumped to v1.15.6

🤖 Generated with Claude Code