…urce exhaustion

Stability fixes for the Vulkan backend discovered through sustained
stress testing on AMD RDNA 2 hardware and Mesa dzn (Vulkan on D3D12 in
WSL2), first published as part of flutter#183382 and rebased onto the current
FenceWaiterVK submission architecture.

Device loss handling:
- ContextVK gains an atomic device_lost_ flag. CreateCommandBuffer()
  and CommandQueueVK::Submit() short-circuit once the device is lost,
  since any Vulkan call on a driver that entered a corrupted OOM state
  can access-fault inside the ICD.
- On vkQueueSubmit failure, tracked objects are abandoned without
  making Vulkan calls (AbandonForDriverCrash on command pools and
  descriptor pools), the device is marked lost, and per-heap memory
  budgets are logged for diagnosis.
- FenceWaiterVK releases rather than destroys the fence when the
  submit callback fails; some drivers partially track the fence even
  though the submission failed, and vkDestroyFence then crashes
  (VUID-vkDestroyFence-fence-01120 observed on AMD).

Submission backpressure:
- CommandQueueVK caps concurrent in-flight submissions (3) with a
  condition variable, releasing the slot from the fence completion
  callback. Prevents unbounded host memory growth when the CPU
  outpaces the GPU.
- ContextVK::FlushCommandBuffers() submits in chunks of 64 to keep
  per-submit driver allocations bounded on frames that accumulate very
  large command buffer counts.
- GPUSurfaceVulkanImpeller (embedder-managed image path) adds a
  two-entry frame fence ring mirroring the KHR swapchain's
  backpressure, with a bounded wait that skips the frame under extreme
  GPU pressure. Image views for embedder images are now cached instead
  of being allocated (and leaked) per frame, and in-flight frames are
  drained before views are destroyed on resize or teardown.

Command pool lifecycle:
- BackgroundCommandPoolVK releases its handles without Vulkan calls
  when the recycler is gone; the device may already be destroyed at
  that point. This is the same class of teardown race as the
  CommandPoolVK destructor fix that landed in flutter#186749.
- The recycled pool list is capped at 8 entries, evicting oldest
  first.
- unused_command_buffers_ is annotated IPLR_GUARDED_BY(pool_mutex_).

Descriptor pools:
- Reset via vkResetDescriptorPool on reclaim. Reclaimed pools
  previously stayed at capacity and produced
  VK_ERROR_OUT_OF_POOL_MEMORY on every reuse.

Barrier and render pass correctness:
- Six barrier fixes in the blit pass: pre-copy barriers use transfer
  stage and access flags, post-copy barriers flush transfer writes,
  and mipmap generation barriers match the actual current layout.
  Fixes corrupted glyph atlases and SYNC-HAZARD-WRITE-AFTER-WRITE
  reported by the synchronization validation layer on AMD RDNA 2.
- RenderPassBuilderVK moves subpass dependencies to a counted builder,
  drops eByRegion from external (VK_SUBPASS_EXTERNAL) dependencies
  where it has no meaning per Vulkan spec section 7.1, and gains
  SetFramebufferFetchEnabled() so input attachment references and
  self-dependencies are omitted on drivers without framebuffer fetch
  support. The flag is wired through pipeline and render pass creation
  and the compat render pass used for PSO construction.

Driver workarounds:
- DriverInfoVK exposes GetDriverID() (Vulkan 1.2) and detects Mesa
  dzn.
- New skip_sub_region_buffer_to_image_copy workaround: Mesa dzn
  reports minImageTransferGranularity of (0,0,0) and corrupts textures
  on sub-region buffer-to-image copies; the blit pass stages such
  copies through a full-size temporary texture.

Memory management:
- The VMA buffer pool is capped at 256 blocks (about 1 GB); the pool
  otherwise grows without bound when high-water-mark demand spikes and
  fragmentation prevents block reuse.
- Image allocation failure paths no longer leak the VMA allocation
  when image view creation fails.
- On Windows, the working set is periodically trimmed when Resizable
  BAR mappings inflate RSS far beyond actual VMA usage (gated by
  cooldown, RSS threshold, and RSS-to-VMA ratio).

KHR swapchain robustness:
- The synchronizer fence is re-signaled with an empty submit on every
  early return after a failed or unusable acquireNextImageKHR
  (including the surface-lost path added in flutter#183338). The fence was
  reset by WaitForFence, and without a new signal the next wrap-around
  to the same synchronizer deadlocks in waitForFences with an infinite
  timeout.
- AcquireNextDrawable short-circuits when the device is marked lost.
- Zero-extent surfaces (minimized windows) skip the frame instead of
  attempting swapchain recreation, preserving recovery on restore.

Embedder mode:
- CapabilitiesVK enumerates instance layers in embedder mode so that
  validation layers can be detected and enabled when requested.

Follow-ups to the first review pass on the Vulkan hardening change:

- AllocatedTextureSourceVK: destroy the already-created image views
  before the image when a render target view fails to create partway
  through the per-subresource view loop.
- BlitPassVK: pick the destination barrier's source scope from the
  texture's tracked layout in OnCopyTextureToTextureCommand, mirroring
  OnCopyBufferToTextureCommand. The unconditional eTransferWrite scope
  can trip best-practices validation when the destination was last
  sampled; the WAW protection for back-to-back transfer writes in the
  atlas growth path is preserved in the eTransferDstOptimal branch.
- AllocatorVK: make the Windows working-set trim cooldown a
  process-wide atomic instead of thread_local, since EmptyWorkingSet
  affects the whole process.
- GPUSurfaceVulkanImpeller: on a lost device, abandon the cached image
  views and frame fences instead of waiting on or destroying them, in
  both the destructor and the resize drain, matching the
  AbandonForDriverCrash policy. Adds a teardown-after-device-loss test.

…osition

Adds an opt-in Vulkan rendering path to the Windows embedder: Impeller
renders with its existing Vulkan backend and the content is presented
through DXGI and DirectComposition, so the OS compositor owns
presentation. There is no VkSurfaceKHR and no Vulkan swapchain in this
path, addressing the review feedback on the original proposal that a
KHR swapchain would block compositor integration, resize
synchronization, and future platform views.

Activation uses engine switches, the same mechanism as the existing
Impeller opt-in, and requires both switches:

  --enable-impeller --impeller-backend=vulkan

Nothing changes otherwise; ANGLE remains the default and the fallback.
Wiring these switches into the flutter tool's command line is left to a
follow-up, so for now they are supplied through an embedder's switch
list or the engine switch environment protocol.

Components:

- VulkanManager: dynamic vulkan-1.dll loading (a missing runtime falls
  back before engine start), instance and device creation with no
  windowing extensions. Device selection requires a graphics queue, a
  valid adapter LUID, and Direct3D 11 texture import support, verified
  per device via vkGetPhysicalDeviceImageFormatProperties2, so a
  successful Create() guarantees the interop works. Every rejection
  logs its reason.
- DCompPresenter: a Direct3D 11 device on the LUID-matched adapter
  allocates the shared render target textures (keyed mutex, NT handle)
  and presents them by copying into a flip-model composition swapchain
  rooted in a DirectComposition visual. Content reaches the screen
  only through the DComp commit, so window chrome and Flutter content
  resize atomically.
- VulkanImportedImage: binds a VkImage to a shared texture's memory
  (dedicated allocation, VkImportMemoryWin32HandleInfoKHR). The import
  direction is dictated by the drivers: Direct3D 11 texture memory is
  reported to Vulkan as import-only (measured on AMD Adrenalin as
  DEDICATED_ONLY | IMPORTABLE), so the allocation originates on the
  Direct3D side, the same direction Chromium and Dawn use.
- CompositorVulkan: a FlutterCompositor whose backing stores pair a
  shared texture with its Vulkan import. The engine host-syncs all
  layers before the present callback, and the Direct3D side brackets
  its access with the keyed mutex. Platform views are rejected with a
  clear error; the visual tree architecture is what enables them
  later.
- Impeller Vulkan backing stores: the engine renders each compositor
  backing store into the imported image with Impeller. The image is
  wrapped as the resolve target of an MSAA color attachment with a
  depth-stencil, matching SurfaceVK::WrapSwapchainImage, and reported
  as a swapchain image so the render pass leaves it in
  VK_IMAGE_LAYOUT_GENERAL rather than a sampled layout the imported
  image does not support. GPUSurfaceVulkanImpeller gains a
  render_to_surface flag: when an external view embedder is present the
  root surface is a no-op and all content arrives through backing
  stores, matching the OpenGL Impeller path.
- FlutterWindowsEngine: parses --impeller-backend=vulkan next to the
  existing enable-impeller handling, skips EGL initialization entirely
  when Vulkan is active, and supplies a kVulkan renderer config whose
  image callbacks are never invoked because the compositor is
  supplied. The SDF rendering default is an ANGLE/OpenGL Impeller
  option and is not applied when the Vulkan backend is active.

Tests (hardware-dependent cases skip cleanly without Vulkan):

- VulkanManagerTest: loading, create-or-null, LUID validity, required
  extensions, no windowing extensions ever, proc resolution, teardown.
- VulkanImportedImageTest: argument validation.
- DCompPresenterTest: unknown LUID rejection, present-before-bind
  rejection, the full allocate/import/present/evict pipeline against a
  live DirectComposition tree, in-place swapchain resize, and repeated
  lifecycle cycles.
- FlutterWindowsEngineTest: the backend requires the explicit switch,
  is ignored without Impeller, either activates with ANGLE skipped or
  falls back without failing engine construction, and does not enable
  SDF rendering when Vulkan is active.
- GPUSurfaceVulkanImpeller: with render_to_surface disabled the root
  surface yields a no-op frame and never pulls an image from the
  delegate.