fix(win): compile cleanly with MinGW GCC

[Oxygen56]

Fixes #1225

What does this PR do?

Makes the Windows sources compile cleanly with MinGW GCC when warnings are treated as errors.

• Removes a redundant DWORD range comparison that GCC reports as always false on 64-bit Windows. The existing MAXDWORD guard keeps the subsequent +1 safe, while calloc retains allocation-overflow handling.
• Converts dynamically resolved Windows functions through GCC's generic void (*)(void) function-pointer type before assigning their concrete signatures.
• Applies the same conversion to the Windows IPC regression test helpers.

Root cause

MinGW defines FARPROC as an unspecified-parameter function pointer. Direct casts from it to concrete Win32 function signatures trigger -Wcast-function-type. Separately, a DWORD can never exceed the 64-bit SIZE_MAX-based bound, so -Wtype-limits rejects that comparison under -Werror.

Verification

• Unmodified origin/main reproduced both warning classes with x86_64-w64-mingw32-gcc 16.1.0 -Wall -Wextra -Werror.
• The affected production translation units compile cleanly with the same MinGW GCC flags after the fix.
• The Windows IPC test translation unit compiles cleanly for the affected warning class; -Wno-stringop-overflow was used only to isolate pre-existing unrelated diagnostics in that file.
• make -f Makefile.cbm test — 6776 passed, 4 skipped.
• make -f Makefile.cbm lint-ci — passed.
• scripts/check-dco.sh origin/main..HEAD — passed.

Checklist

• Every commit is signed off (git commit -s) — required, CI rejects
  unsigned commits (DCO, see CONTRIBUTING.md)
• Tests pass locally (make -f Makefile.cbm test)
• Lint passes (make -f Makefile.cbm lint-ci)
• New behavior is covered by a test (reproduce-first for bug fixes)

[DeusData]

Thanks for the focused portability cleanup. The code change is technically reasonable and the current reported CI is green, but that CI uses Windows CLANG64 and does not compile with MinGW GCC, so it does not protect the behavior this PR claims. Supporting MinGW GCC is a compiler-support policy decision and would require a maintained compile lane or equivalent durable RED check. The branch is also nine commits behind main. No need to rebase or add infrastructure until the support direction is confirmed.

[DeusData]

Thanks for this, and sorry for the delayed first response. Queued for review.

MERGEABLE with all 28 checks green and a tidy +30/-25 across four files — nothing blocking on your side.

MinGW GCC clean compilation is valuable specifically because it is the toolchain most likely to drift silently; a build that only works under one Windows compiler tends not to stay working.