Remove AsyncPdmObjectVectorDeleter and delete PDM objects synchronously

[magnesj]

Removes caf::AsyncPdmObjectVectorDeleter and PdmChildArrayField::deleteChildrenAsync(), and deletes PDM objects synchronously instead. Closes #14491.

Problem

Deleting a PDM object is not a local operation. PdmObjectHandle::prepareForDelete() mutates state owned by other objects:

for ( it = m_pointersReferencingMe.begin(); it != m_pointersReferencingMe.end(); ++it )
    ( **it ) = nullptr;                     // writes into PdmPointer members owned by other objects
m_pointersReferencingMe.clear();            // set mutated by every PdmPointer ctor/dtor, anywhere

m_pointersReferencingMe is an unsynchronised std::set that PdmPointerImpl::addReference() and removeReference() touch on every PdmPointer construction, copy, assignment and destruction. Destroying an object on a worker thread therefore races with the main thread on the shared object graph.

Async deletion also nested: ~RimSummaryCaseMainCollection called m_ensembles.deleteChildrenAsync(), the spawned thread ran ~RimSummaryEnsemble, which called m_cases.deleteChildrenAsync() again. Crash reports from release 2026.06.1:

[14] AsyncPdmObjectVectorDeleter<RimSummaryEnsemble>::start()::{lambda}   worker thread
[12] RimSummaryEnsemble::~RimSummaryEnsemble()
[11] PdmChildArrayField<RimSummaryCase*>::deleteChildrenAsync()           spawns a second thread
[10] AsyncPdmObjectVectorDeleter<RimSummaryCase>::AsyncPdmObjectVectorDeleter()
[9]  std::_Rb_tree<caf::PdmObjectHandle**>::_M_erase                      m_pointersReferencingMe
[8]  std::__new_allocator::deallocate                                     SIGSEGV

Why removal rather than hardening

The mechanism does not pay for itself. Measured teardown of already loaded summary readers, Windows, MSVC, system allocator:

Model	Cases	Sequential	Parallel	Speedup	PDM share of teardown
Drogon	100	0.064 s	0.048 s	1.34 x	1.8 %
Drogon	397	0.242 s	0.237 s	1.02 x	2.8 %
Heidrun, 44 MB UNSMRY	10	0.034 s	0.050 s	0.68 x	0.4 %

free() is serialised inside the allocator, so at ensemble scale the speedup disappears, and for large payloads parallel release is slower than sequential. Teardown is cheap in absolute terms either way, and the PDM bookkeeping the race is about accounts for 0.4 to 2.8 percent of it.

Caveat on the numbers: the readers were loaded on one thread, while loadFileSummaryCaseData() loads them with OpenMP. Under an allocator with per-thread arenas, glibc for instance, that changes which arena the memory is freed to and could change the parallel column. The measurement is from Windows, the crash reports are from Linux builds.

Changes

• Delete cafAsyncObjectDeleter.h and .inl, and PdmChildArrayField::deleteChildrenAsync().
• Add caf::PdmObjectHandleTools::deleteObjects() for deleting a vector of objects that is no longer owned by a child array field. Used by RicCloseSummaryCaseFeature.
• RimSummaryCaseMainCollection::~, RimSummaryEnsemble::~, RimSummaryEnsemble::replaceCases() and RimSummaryFileSetEnsemble::createSummaryCasesFromEnsembleFileSet() used clearWithoutDelete() plus a manual delete loop to work around the race. They now call deleteChildren() directly.

Note on issue 12262

The observer disconnection does not depend on clearWithoutDelete(). ~Signal() calls removeObservedSignal() on every observer, so a deleted child detaches itself:

virtual ~Signal()
{
    for ( auto observerCallbackPair : m_observerCallbacks )
        observerCallbackPair.first->removeObservedSignal( this );
}

Verified by asserting the observed signal count with and without clearWithoutDelete() in deleteChildren(), it reaches zero either way. #12262 was a race in the async path, where ~Signal() mutated the observer list from a worker thread concurrently with the main thread. With deletion synchronous the ordering is deterministic, so deleteChildren() keeps its original body.

The unit test is renamed to DeletedChildrenDisconnectFromObserver and now asserts the observed signal count directly, 1000 before deletion and 0 after, instead of relying on a crash that only reproduced in a Debug build.

Verification

ResInsight and ResInsight-tests build and link, all 90 cafPdmCore_UnitTests pass.

caf::AsyncWorkerManager has no callers left after this change. It is a separate general purpose utility, so it is left in place.