Windows support: first-class support research and alignment (umbrella)

[mobileskyfi]

Scope

This is the Windows-first-class support umbrella, not a CI refactor issue. The goal is to determine the real quickchr Windows support surface from a Windows-side point of view, and to separate genuine blockers from untested-but-fine paths.

It still affects #29 indirectly: Windows investigations need a regularized way to run targeted lab/manual workflow dispatches outside normal push/PR gating. That workflow shape belongs in #29; the Windows behavior questions stay here.

Hypothesis grounded so far

Core lifecycle works on Windows. Grounded: the full integration suite passed on windows-latest / TCG: 56 pass / 0 fail / 3 skip (run 27097457831, 2026-06-07). scp upload/download works without sshpass; SLiRP + port-forward validated. See .github/instructions/ci.instructions.md.

Repro plan / open gaps to triage

• Named-socket / socat channel on Windows (named pipes vs. AF_UNIX).
• TAP-Windows detection + setup docs.
• QGA +8 offset (KVM-gated; confirm under WHPX or document as unsupported).
• Snapshot smoke (qemu-img, savevm/loadvm) on a Windows host.

Prefer a real Windows run (CI matrix, lab workflow, or local Windows VM) over inferring. One CI red is a signal, not a fact.

Done-when

A Windows-POV review records findings in test/lab/windows/REPORT.md and either breaks confirmed gaps into their own Task/bug issues or closes them as non-issues.

Anchor issue for future agents: before concluding "X does not work on Windows", read this plus the lab report and reproduce.

[mobileskyfi]

Full-suite-on-Windows result (run 28749608475, 2026-07-05)

First full-suite Windows run since the CI refactor made it dispatchable (platforms=all now honestly means everything — PR #75): 59/60 tests pass in ~26 min under TCG. Per-file: anchor, device-mode, examples-smoke, exec (20 tests), file-transfer, forward-cli, library-api, license, provisioning (11 tests, 491s), settings-secure-login-cli, start-stop — all green.

The single failure closes a known validation gap from the umbrella list ("snapshot smoke — unvalidated"):

(fail) disk support > monitor savevm/loadvm restores guest state on qcow2 boot disk [43735.36ms]
QuickCHRError: Monitor command timed out   code: BOOT_TIMEOUT
    at src/lib/channels.ts:92

Diagnosis (from the log, not yet locally reproduced): monitorCommand defaults to a 5s timeout (src/lib/channels.ts:76). savevm must serialize the full VM state (256 MB RAM + device state) — fast under KVM/HVF, but under TCG on a 4-core hosted runner it plausibly needs well over 5s. So Windows snapshots are likely functional but mis-timed, not broken — the same 4-layer #31 fix path (qcow2 boot disk) got as far as issuing savevm. Also note the error code is misleading: a monitor-command timeout reports BOOT_TIMEOUT.

Done-when: reproduce locally (x86 CHR under forced TCG works on any host), size a savevm-appropriate monitor timeout (or accept a timeout parameter at the snapshot.save() call site — state size / TCG factor aware), and re-dispatch integration.yml -f platforms=windows-x86 -f test-filter=disk.test.ts to confirm. The wrong BOOT_TIMEOUT code on monitor timeouts can be fixed alongside (#54 territory).