win: high-resolution poll timeouts via waitable timer + IOCP

[robobun]

GetQueuedCompletionStatusEx's ms timeout rounds to the system clock tick (~15.6 ms by default), so a 1 ms uv_timer fires ~15 ms late on an idle Windows box unless another process has raised the tick rate.

On Win10 1803+ / Server 2019+, arm a CREATE_WAITABLE_TIMER_HIGH_RESOLUTION waitable timer for the poll deadline and associate it with the loop's IOCP via NtAssociateWaitCompletionPacket. When it fires, the kernel posts a completion with lpOverlapped == NULL, which the dequeue loop already treats as a pure wakeup, and GQCS itself blocks with INFINITE so its coarse ms timeout never applies. This is the same approach Go's runtime uses (golang/go#44343).

On older Windows, fall back to timeBeginPeriod(1) once per process.

Measured on Windows Server 2019 (idle) via Bun's setTimeout:

	before	after
setTimeout(cb,1)	15.52 ms	1.41 ms
setTimeout(cb,5)	15.62 ms	5.24 ms

Companion Bun PR with the test + build-side patch: oven-sh/bun#34834

[robobun]

Ran an adversarial review against this diff (8 probe dimensions, 2-vote refutation). Four concerns survived; all addressed in b5c4eca:

	concern	resolution
1	uv__hrtimer_init ran before 4 fallible uv_loop_init steps; handle leak on fail-path	moved to just before return 0 (after uv__loops_add)
2	3 syscalls (cancel/set/associate) on every poll with a finite timeout, including an HTTP server's 1s/4s housekeeping timers	arm only when timeout <= 100; far-away deadlines fall through to GQCS's ms wait. Bun.serve hello-world throughput on Windows debug (oha 10s/50 conn) was already within noise of main before this (11,484 vs 11,434 req/s); with the guard the arm path is unreachable there
3	fork PR and Bun's patch file had diverged on the uv__hrtimer_init signature	synced; both single-arg now
4	Go (the cited reference) passes RemoveSignaledPacket=TRUE to NtCancelWaitCompletionPacket; this used FALSE and ate a spurious iteration instead	switched to TRUE

Also manually verified on Windows Server 2019: I/O-beats-timer stress (100/100 fetch wins, 0 early fires), timer-beats-I/O (30/30 timer wins at 1ms vs 10ms server), 8 parallel Worker loops (medians 1.19-1.56ms), setInterval(16) avg 16.37ms, setTimeout(100) at 103.49ms.