fix: preload SwiftShader before the GPU sandbox locks down again

[codebytere]

Description of Change

Fixes #52700

On Windows the GPU process turns on MITIGATION_FORCE_MS_SIGNED_BINS once its sandbox is up, so any of our own DLLs it needs later have to be loaded before that. vk_swiftshader.dll used to be preloaded there unconditionally; CL 7636200 (Chromium 148, so Electron 42 and later) made it conditional on SwiftShader being asked for on the command line. WebGPU's fallback adapter on Windows is SwiftShader over Vulkan (Dawn's D3D backends return no adapters for forceFallbackAdapter; WARP is only the software path for GL), and WebGPUDecoderImpl still asks for it when no D3D12 adapter is usable or a page passes forceFallbackAdapter, so that load is now rejected by Code Integrity (event 3033). For a normal install that just means no fallback adapter; for AppX/MSIX packages the loader treats it as package tampering, kills the GPU process and marks the package as needing repair, which is what #52700 and the linked reports describe. 41 is unaffected because its Chromium predates the CL.

This reverts that CL's gpu_init.cc change so the DLL is preloaded unconditionally again, as in 41; a narrower condition is proposed upstream at https://chromium-review.googlesource.com/c/chromium/src/+/8286976 and the patch goes away once that or an equivalent lands.

Verified on Windows 11 arm64 with an MSIX-installed Electron 42.9.2 app: navigator.gpu.requestAdapter() alone produces the 3033 and kills the GPU process with 0x060C201E (package goes to Modified, NeedsRemediation); the same build unpackaged logs the 3033 but survives; Electron 41.10.7 never loads the DLL late; and forcing the preload on 42 (--enable-unsafe-swiftshader) makes the events and the crash go away.

Checklist

• I have filled out the PR description
• I have reviewed and verified the changes
• PR release notes describe the change in a way relevant to app developers, and are capitalized, punctuated, and past tense.

Release Notes

Notes: Fixed the GPU process being terminated in AppX/MSIX packaged apps on Windows when WebGPU fell back to SwiftShader.

[deepak1556]

enable_webgpu is a broader gate that would make the other conditions no-op for the majority cases. https://groups.google.com/a/chromium.org/g/blink-dev/c/yhFguWS_3pM did make WARP the default fallback for GL path but why was this code added with webgpu path not using WARP as default.

Seems fine to restore the old path but couldn't we just revert https://chromium-review.googlesource.com/c/chromium/src/+/7636200 for the crash while he upstream CL is being worked on ?

[codebytere]

@deepak1556 yeah, a straight revert is simpler here - switched the patch to revert 7636200's gpu_init.cc hunk in 8d8626b and left the gating question to the upstream CL. on warp: dawn's d3d backends return no adapters at all for forceFallbackAdapter (third_party/dawn/src/dawn/native/d3d/BackendD3D.cpp, DiscoverPhysicalDevices), so webgpu's fallback adapter on windows is swiftshader-over-vulkan by design and warp only ever covered the gl/angle software path; 7636200 seems to have assumed otherwise.

[deepak1556]

Thanks!

[release-clerk]

Release Notes Persisted

Fixed the GPU process being terminated in AppX/MSIX packaged apps on Windows when WebGPU fell back to SwiftShader.

[trop]

I have automatically backported this PR to "43-x-y", please check out #53197

[trop]

I have automatically backported this PR to "44-x-y", please check out #53198

[trop]

I have automatically backported this PR to "42-x-y", please check out #53199