Enforce LoginGraceTime in wolfsshd on Windows

Problem

wolfSSHD_ConfigNew() defaults LoginGraceTime to 120 seconds, but on Windows
HandleConnection() only logged a warning and never armed a timer. The
pre-authentication accept loop ran as long as the timeout flag was clear and
wolfSSH_accept() returned WS_WANT_READ/WS_WANT_WRITE, so a Windows build
left unauthenticated connections open indefinitely despite the configured (or
default) grace time — a fail-open daemon default.

A second, latent issue: the timeout flag was a single file-scope variable. This
was safe under the Unix fork-per-connection model, but on Windows daemon
connections are threads sharing memory, so one connection timing out would have
tripped every in-flight handshake.

Changes

• Windows enforcement via CreateThreadpoolTimer. The grace timer is armed
  before wolfSSH_accept(); its callback marks the connection as timed out, and
  it is cancelled both after the accept loop and on authentication success —
  mirroring the existing Unix alarm()/SIGALRM path. UserAuthResult()
  reaches its connection through wolfSSH_SetUserAuthResultCtx().
• Per-connection timeout flag. Moved the timeout flag out of the file-scope
  global into WOLFSSHD_CONNECTION. The Unix SIGALRM handler reaches the
  active connection via a per-process activeConn pointer (POSIX signal
  handlers take no user-data argument).
• Logging: wolfSSHDLoggingCb now flushes after each line so log consumers
  (e.g. tests reading the file while the daemon runs) see entries promptly; the
  per-connection grace/timeout summary line was demoted from WS_LOG_ERROR to
  WS_LOG_INFO.

Tests

• Reworked sshd_login_grace_test.sh to drive the pre-auth stall
  deterministically with a raw TCP connection instead of an interactive client
  password prompt (which never stalled without a TTY under CI), and re-enabled
  it in run_all_sshd_tests.sh.
• Added sshd_login_grace_test.ps1 and a windows-check workflow step so the
  Windows enforcement path is exercised in CI.