Windows has no gap-suite baseline, so nothing ratchets #10406

scripts/run_gap_tests.sh picks its snapshot per platform:

if [[ "$host_platform" == "linux" ]]; then
  default_snapshot="test-parity/gap_snapshot.json"
else
  default_snapshot="test-parity/gap_snapshot.${host_platform}.json"
fi

test-parity/gap_snapshot.windows.json does not exist, so every Windows run
falls back to the Linux baseline with a loud NOTE and compares against
expectations that are not Windows'. There is nothing to ratchet against: a
Windows regression cannot turn a build red, and a Windows-only fix cannot be
recorded as progress.

First measurement, for whoever establishes it

Full gap suite on Windows 11 / MSVC against the pinned Node 26.5.1, from #10385
(PR #10403), with target/perry-auto-* cleared so #10404 does not contaminate
it:

• 790 pass / 39 parity-fail / 0 compile-fail / 5 crash of 835.
• All 5 crashes are test_gap_http2_wire_* (client_ping, goaway_recv,
  goaway_send, session_lifecycle, settings_ack), every one a 10s timeout
  rather than a memory fault. Windows validation work order for the turnloop migration (PR #10354) #10385 designates the http2 fixtures an
  expected-fail ratchet, so they are reported rather than triaged.

Two caveats before anyone commits this as the baseline:

1. The 39 parity failures are untriaged as Windows-specific versus
   pre-existing — that needs the same suite on the merge base, which Windows validation work order for the turnloop migration (PR #10354) #10385 did
   not get to.
2. run_gap_tests.sh refuses to park a crash in a snapshot at all (test_gap_fetch_instanceof_5433 SIGSEGVs, and the gap snapshot launders the crash as an accepted gap (both referenced issues closed) #7526), so
   the 5 http2 crashes cannot go in as-is; they need fixing or excluding first.

Related: #10404 (stale auto-optimize archives fabricate COMPILE_FAILs — clear
target/perry-auto-* before measuring anything).