ci: force external linkmode for static MinGW link in Windows GUI builds

[javi11]

Summary

Fixes the verify-windows-gui-dlls CI failure where build/bin/postie.exe still imported libstdc++-6.dll and libwinpthread-1.dll despite the recent attempts at static linking (#204, #206).

Root cause

• The Wails GUI build used -ldflags=\"-extldflags=-static\" without -linkmode external. Go silently ignores extldflags unless external linkmode is explicitly selected, so -static never reached the linker.
• CGO_LDFLAGS ended with -Wl,-Bdynamic, which reverted the linker back to dynamic mode for any libs cgo/wails appended after -lpthread — including libstdc++ and libwinpthread.
• The step ran under the default PowerShell shell instead of msys2 {0}, so gcc could resolve to a different toolchain than the MSYS2 mingw64 one set up earlier.

The CLI Windows build did not have this problem because it already passed -linkmode external -extldflags '-static' and ran under bash.

Changes

In both dev-build.yml and release.yml for the build-gui-windows job:

• Add -linkmode external to wails ldflags so -extldflags=-static is honored.
• Drop the -Wl,-Bstatic -lpthread -Wl,-Bdynamic dance from CGO_LDFLAGS — gcc -static covers pthread already.
• Run the build with shell: msys2 {0} so the MINGW64 toolchain is unambiguously on PATH.

Test plan

• CI build-gui-windows succeeds.
• verify-windows-gui-dlls shows no libgcc_s_seh-1.dll, libstdc++-6.dll, or libwinpthread-1.dll in the imports — only KERNEL32.dll and api-ms-win-crt-* remain.
• Same verification passes in the release workflow on the next tagged build.