#14230 Fix deadlock when importing wells from OSDU

The GUI thread deadlocked on a non-recursive QMutex during OSDU well
import. The download-completion slots and DataLoadController::onTaskFinished
held a mutex while triggering progress updates, which call
QApplication::processEvents(). That re-enters the event loop and dispatches
another queued parquet-download-complete event for a different well, whose
handler then blocks trying to lock the same mutex.

Release the mutex before emitting taskDone in the OSDU well path and well
log data loaders, and before calling incrementProgress() in onTaskFinished.
The map access that the mutex protects stays inside the locked scope; the
captured ProgressInfo outlives the call (kept alive by blockUntilDone) and
incrementProgress() is thread-safe via self-marshaling to the GUI thread.

Fixes #14230.

Fwk/AppFwk/cafDataLoader/cafDataLoadController.cpp

@@ -141,7 +141,16 @@ void DataLoadController::blockUntilDone( const QString& dataType )
 //--------------------------------------------------------------------------------------------------
 void DataLoadController::onTaskFinished( const caf::SignalEmitter* emitter, QString dataType, int taskId )
 {
-    QMutexLocker locker( &m_mutex );
-    m_pendingTasksByType[dataType]--;
-    if ( m_progressInfos.find( dataType ) != m_progressInfos.end() ) m_progressInfos[dataType]->incrementProgress();
+    ProgressInfo* progressInfo = nullptr;
+    {
+        QMutexLocker locker( &m_mutex );
+        m_pendingTasksByType[dataType]--;
+        auto it = m_progressInfos.find( dataType );
+        if ( it != m_progressInfos.end() ) progressInfo = it->second;
+    }
+
+    // Update progress after releasing the lock. incrementProgress() calls QApplication::processEvents(),
+    // which can re-enter this slot for another finished task. Holding the non-recursive m_mutex across that
+    // re-entrant call would deadlock the GUI thread (#14230).
+    if ( progressInfo ) progressInfo->incrementProgress();
 }