Blocking submit + fence-wait stalls, and the one residual in the streaming path

[CanReader]

src/Graphics/Vulkan/VulkanTexture.cpp:175-176; src/Graphics/Vulkan/VulkanCubemapTexture.cpp:169, :218-219,
:224, :438, :487-488, :493, waits at :682-683; src/Graphics/Vulkan/VulkanIBL.cpp:143-144;
src/Graphics/Vulkan/VulkanBuffer.cpp:314-317, :563

Stall counts: 1 per texture (VulkanTexture.cpp:175-176); 3 per cubemap in LoadCubemap
(transition :169, copy :218-219, transition :224); 3 more in LoadEquirectangular (:438, :487-488, :493);
1 in VulkanIBL (:143-144). All are startup-scoped.

Important scoping correction for whoever acts on this: the mesh streaming path is already clean and
should NOT be "fixed". SetBatchingEnabled(true) at VulkanRenderer.cpp:219 is never turned off, so mesh
uploads batch into FlushPendingCopiesAsync (VulkanBuffer.cpp:581-611, semaphore only), waited at
VK_PIPELINE_STAGE_VERTEX_INPUT_BIT (VulkanRenderer.cpp:538-541): zero per-mesh stalls.

The one residual on the hot path: VulkanBuffer::Cleanup:314-317 calls the synchronous
FlushPendingCopies (fence wait at :563) whenever a buffer with a pending in-batch copy is destroyed
mid-frame: which a voxel chunk streaming workload does routinely.

Severity: perf.

Found by a full audit of the graphics layer. Assessed severity: perf.