win: cache the uv__windows10_version1709() result and check RtlGetVersion's return value

Small hardening follow-up to #5107 ("win: properly initialize OSVERSIONINFOW"). First, thanks for that fix.

For context: we independently root-caused the crash that #5107 fixes, in a long-running production Node service (Node v24.15.0 bundling libuv 1.51.0, Windows 11 build 26200, recurring 0xC0000409 / FAIL_FAST_STACK_BUFFER_OVERRUN_STACK_COOKIE_CHECK_FAILURE at uv__tcp_connect). Three independent crash dumps showed the frame's /GS cookie overwritten byte for byte with the machine's RTL_OSVERSIONINFOEXW tail (wSuiteMask/wProductType etc.), and we built a deterministic repro by painting the stack with accepted dwOSVersionInfoSize values before a connect. While preparing an upstream report we found #5107 had already landed. Two small observations from that analysis still apply at v1.x head:

1. uv__windows10_version1709() re-queries the OS version on every call.

It runs on every uv_tcp_connect() (src/win/tcp.c:860, ahead of the uv__is_loopback() short-circuit, so non-loopback connects pay it too) and on the keepalive path (src/win/tcp.c:94). The Windows version cannot change while a process is running, so the result could be computed once (a static one-shot, or folded into existing one-time init), saving a syscall per connect. It also shrinks the blast radius if a bug of the pre-#5107 kind ever reappears in this helper: because the call sits on every connect, our service turned a small per-call probability into several silent process aborts per day.

2. The return value of pRtlGetVersion is not checked.

The struct fields are trusted unconditionally. With dwOSVersionInfoSize now initialised this is mostly belt and braces, but the API is allowed to fail, and the fields feed real behavioral decisions (fast-loopback and keepalive paths), so returning 0 on failure seems preferable to reading fields the call may not have written.

Happy to share the dump analysis or the stack-paint repro from our investigation if useful.