Transfer writes are not implicitly ordered, so without a barrier the fill could
complete after the copy. This was causing intermittent failures in the
VK_Indirect test when running with KosmicKrisp.
Synchronization validation reports this error:
```
vkCmdCopyBuffer(): WRITE_AFTER_WRITE hazard detected. vkCmdCopyBuffer writes to
VkBuffer [m_IndirectBufferActionCB], which was previously written by
vkCmdFillBuffer[Drawcall callback replay (drawCount=1)].
```
Inside the large EI draw with a count of 256: only check a few EIDs at the start and end of that EI.
Reduces the test time and the EIDs being skipped are not exercising different code paths during replay.
The commands to initialize srcBuf must complete before it is copied. Sync
validation reports this as a READ_AFTER_WRITE hazard. This also fixes a
VK_Image_Layouts test failure when running with KosmicKrisp.
* During capture shutdown on Python < 3.13 the replay thread will try to remove
itself as a debuggable thread which requires being able to run python (holding
the GIL). If the UI thread is the one triggering the capture shutdown and is
running a call from a python script it may hold the GIL while waiting for the
replay thread to close, deadlocking.
* To alleviate this, while the UI thread is about to block on the replay thread
we try to release the python state if we are holding it so that the replay
thread can run python code if needed.
* We already do this in a manual wrapper around BlockInvoke.
* Due to the way Qt works, the owning object acts as if it lives on the thread
which in this case is running an event loop that tries to delete itself.
* Environment variables are not thread safe on linux, but unfortunately linux is
obssessed with them so we must hold our nose and interact with them.
* This change tries to move some modifications earlier into init before anything
else happens to reduce the risk of clashes, as well as removing some reads
that are unnecessary.
baldurk