vulkan: when using transfer queue for async copies, sync on event_wait to avoid race

[0cc4m]

Overview

When async_use_transfer_queue is set (for AMD RDNA GPUs), the async queue did not wait for events yet. On RADV this didn't cause issues, but it could be the source of the issue reported for AMD Windows devices. I can't reproduce it, so this is a guess, but I have verified it does not regress performance or cause incoherent output on Linux.

This is an attempt to fix the issue reported in #25195, could be an alternative to #25196 depending on performance. @liminfei-amd please check if this resolves the race condition. It was the only issue I could find with the transfer queue use.

Requirements

• I have read and agree with the contributing guidelines
• AI usage disclosure: YES, claude wrote the code, I reviewed and tested.

[liminfei-amd]

Thanks @0cc4m, this looks like the right direction! One heads-up: the new sync only fires in event_wait, which needs pipeline parallelism (n_copies > 1), so it won't cover the single-GPU --n-cpu-moe path from #25195. Extending the same submit-level sync to the direct set_tensor_async uploads would close that gap — happy to help!

[0cc4m]

Whoever is using the async copy commands needs to use either ggml_backend_synchronize or events to make sure they are done by the time it wants to use them, and also that the read is done before it writes to the buffer again. That is done for moe expert-upload as well. I don't see the problem you mean.