fix(#371): stop using XCAFApp_Application::GetApplication() singleton — v1.15.17

[gsdali]

Summary

Per upstream maintainer feedback on OCCT#1396
(our #353 repro issue): XCAFApp_Application::GetApplication() "exists solely for compatibility
reasons"; OCCT's own guidance since 7.1 is a private TDocStd_Application per caller, not a
shared singleton. Our #341/#344/#349/#353 race cluster traced back to every document sharing one
process-wide singleton.

• Every OCCTDocument now builds its own private app instance (new TDocStd_Application())
  instead of grabbing the shared singleton — 9 call sites across OCCTBridge_Document.mm/
  OCCTBridge_IO.mm. Confirmed behaviorally equivalent via a ground-truth C++ test before
  touching bridge code.
• Two latent bugs fixed along the way: OCCTDocumentLoadOCAF/OCCTDocumentLoadGLTF each opened
  a document through a different app instance than the one stored on the returned
  OCCTDocument — harmless only because both were the same shared singleton before this change.
• Not a clean win. A dedicated confirmation harness (private app per thread, zero shared
  state, zero serialization, run against the real TSan-instrumented kernel) found two previously
  uncaught races — Resource_Manager::Resource_Manager()'s unsynchronized global Debug, and
  Storage_Schema::ICurrentData()'s unsynchronized global Handle — only reachable once
  application-instance construction genuinely runs concurrently, which never happened under the
  old shared-singleton pattern. Filed upstream as OCCT#1398.
• ocafStoreMutex() (the Concurrent Save/SaveAs to the same format corrupts a shared, cached storage driver instance (SIGSEGV) #349 bridge mitigation) is not redundant after this refactor —
  coverage was expanded (not removed) to also wrap OCCTDocumentDefineFormatBin/BinL/Xml/XmlL/ BinXCAF/XmlXCAF and OCCTDocumentCreateWithFormat, previously outside the lock.
• Upstream kernel PRs for Uncatchable SIGSEGV in parallel swift test run, right after concurrent OBJ imports — possibly related to #341, unconfirmed #344/Concurrent Save/SaveAs to the same format corrupts a shared, cached storage driver instance (SIGSEGV) #349/CDM_Application::myMetaDataLookUpTable unsynchronized (race surfaced by #349 fix) #353 (#1390/
  #1394/#1397)
  were not withdrawn — they fix real bugs in a pattern OCCT's own header still documents as
  the only valid way to get an XCAFApp_Application.

Bridge-only change — no OCCT kernel patch, OCCT.xcframework unchanged. OCCTBridge.xcframework
(the opt-in prebuilt bridge from #339) rebuilt since Sources/OCCTBridge/src/*.mm changed;
Package.swift's URL/checksum bumped to v1.15.17.

Test plan

• Ground-truth C++ test: bare TDocStd_Application vs XCAFApp_Application::GetApplication() — equivalent
• Full swift test (4428 tests / 1285 suites) — clean, re-run twice
• Scripts/tsan-stress.sh swift (bridge-level TSan, 445 tests) — clean
• Scripts/tsan-stress.sh run (kernel-level gate, 9 scenarios incl. new 371-getapplication-singleton-elimination) — clean
• Prebuilt-bridge path (OCCTSWIFT_BRIDGE_PREBUILT=1) — build + OCCTXCAFTests clean
• New upstream OCCT issue filed for the two newly-found races (OCCT#1398)
• New OCCTSwift issue (Stop using XCAFApp_Application::GetApplication() singleton — per-instance TDocStd_Application instead #371) filed and closed by this PR

🤖 Generated with Claude Code