Ship the debug protobuf DLLs the Windows build actually imports

The published Windows zip cannot start. Its exe imports libprotobufd.dll and the debug
abseil_dll.dll - objdump on the shipped binary says so - and the folder contains
libprotobuf.dll and the release abseil instead. The loader fails before main(), so there
is no window and no log: STATUS_DLL_NOT_FOUND and nothing else.

The build is `nmake debug` and defaults.pri picks the debug half of vcpkg to match the
CRT, which puts those DLLs in vcpkg's debug\bin. Deploy copied only bin. The step
immediately above it, which runs the tests, has known about debug\bin since it was
written - its comment even names the 0xC0000135 this produces - and the knowledge never
made it eight lines down.

Both halves are copied now, debug last so it wins abseil_dll.dll, the one name they
share. The release copies are dead weight rather than a hazard: nothing imports them.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Author: nickolas122

.github/workflows/main.yml

@@ -670,7 +670,14 @@ jobs:
             if ($LASTEXITCODE -ne 0) { throw "windeployqt failed: $LASTEXITCODE" }
             cp ../../../icons/iOS/iTunesArtwork@2x.png .
             cp ../../AppxManifest.xml .
+            # Both halves, debug last so it wins the names they share. This is
+            # `nmake debug`, so the exe imports libprotobufd.dll and the debug
+            # abseil_dll.dll - and those live in debug\bin, which this step was not
+            # copying. The result was a published zip whose exe cannot start at all:
+            # STATUS_DLL_NOT_FOUND before main(), no window and no log to say why.
+            # The test step above has known about debug\bin since it was written.
             Copy-Item -Path "$vcpkg\bin\*.dll" -Destination . -Verbose
+            Copy-Item -Path "$vcpkg\debug\bin\*.dll" -Destination . -Force -Verbose
             mkdir adb
             cp ../../adb/* adb/