feat(ci): establish full Windows Go suite coverage with a staged required-check rollout

Start in .github/workflows/ci.yml to see the Linux go test ./... job and the selected Windows jobs, then compare them with the full suite. The failing tests named in the issue are TestAgentContractArtifactCurrent, TestStartupCancellationOwnedLockEOF, TestClaudeHookResponseValidation and TestCodexUnixUserPromptSubmitDetachesPromptPersistenceStdin. Done means a recorded hosted windows-latest baseline for go test ./... with commit, toolchain, command and exit status, and each failure classified; the rollout decision belongs to maintainers.

Existing Issue Search

• I searched existing issues and will add evidence to a canonical tracker when applicable.

Open/closed searches: Windows CI in:title; Windows test suite in:title,body; and exact windows-latest plus go test ./.... No equivalent central suite-coverage tracker was found in the bounded results. Historical closed reports #818, #1727 and #1860 concern specific Windows test failures, not full-suite CI coverage. Do not reopen them or create one issue per observed symptom without establishing a separate root cause.

Observed Consequence

Linux integration checks can pass while Windows full-suite behavior remains unqualified. Current Windows jobs exercise selected setup, MCP process-lifetime and cloud wrapper cases, not the complete Go suite. A green Linux run and a failing Windows development run therefore answer different questions; maintainers lack a reproducible hosted Windows baseline to distinguish product portability defects, test-fixture assumptions and local environment prerequisites.

Desired Outcome

Maintainers can assess the same Go suite on Linux and Windows with aligned project toolchains and reproducible dependency availability. Windows failures have explicit ownership/classification, and stable Windows coverage becomes an enforceable integration signal rather than remaining indefinitely informational. Existing Linux coverage remains intact.

Affected Area

Other — repository CI, cross-platform Go testing and contributor verification guidance.

Release Context

Coverage improvement, not a new product-regression claim or release-eligibility assertion. Main inspected at 90822c759f16d70b8225f83bc15b8a2badf2e80e; current workflow uses Go1.25.10 for Linux and selected Windows jobs. Triggering comparison: PR #1889, head3dd41c4aa3c70d0691f7cd49c12471c3413d8b2b, base42efc9f497e3bf8efe12ea1129b52afb2705e287. This tracker is separate from that endpoint delivery and #1350.

Workarounds and Constraints

A local Windows Go1.26.4 offline full-suite run failed while GitHub Linux Go1.25.10 passed. Those are not equivalent environments. The local run cannot prove a regression in PR #1889 or that every failure is pre-existing/environment-only. No baseline/candidate Windows comparison has established causality.

Known local observations, for triage rather than assumed causes:

• Dashboard setup could not resolve golang.org/x/net v0.57.0 because GOPROXY=off and the dependency was absent locally.
• TestAgentContractArtifactCurrent reported stale generated metadata; the test compares raw bytes. Its exact failure cause remains unproven.
• TestStartupCancellationOwnedLockEOF failed reading Windows-locked files.
• TestClaudeHookResponseValidation observed CRLF instead of LF.
• TestCodexUnixUserPromptSubmitDetachesPromptPersistenceStdin did not finish its stdin probe; exact cause remains unproven.

Local focused runtime tests and the affected server package passed. Local lint did not execute after full-suite failure; it did not fail. Hosted lint passed separately and checks new issues only.

Do not discard genuine Windows failures because Linux is green, or automatically treat an incomparable local run as a general integration veto. Preserve existing assertions and avoid blanket skips, forced success, global TEMP/cache changes or production timeout relaxation as substitutes for diagnosis.

Additional Context

Evidence:

• Current pinned CI workflow: Linux go test ./..., E2E and plugins; selected Windows checks only.
• Observed hosted CI run38672876655: actual checkout798f70f8397d9d1da3b4c92691fac3fba457b932 merges head3dd into base42ef; actual Go1.25.10 linux/amd64; full Go suite passed including dashboard, MCP, server, Store and plugin, plus E2E, plugin checks and incremental lint. Performance Ratchet was skipped; CodeRabbit technical review was skipped at the draft snapshot. These do not qualify the full Windows suite.

Accepted phased scope / acceptance criteria:

• Establish a clean hosted windows-latest baseline running go test ./... with the same project Go version used by Linux and normal dependency availability; record commit, toolchain, relevant shell prerequisites, command, exit status and diagnostics.
• Initially keep the new Windows full-suite check observational/non-required while obtaining a baseline. Preserve all current Linux checks and existing selected Windows coverage.
• Classify each failure as a product portability defect, a nonportable test fixture, an unavailable prerequisite, or genuinely Unix-only behavior. Establish comparable baseline/candidate evidence before attributing a regression. Link existing canonical root-cause issues where applicable instead of multiplying symptom trackers.
• Fix product defects in the owning implementation, fixture assumptions in tests, and runner prerequisites in setup. Explicitly separate genuinely Unix-only tests with documented justification; a failure alone is not justification to skip it. Preserve the same observable behavior contracts across platforms.
• Define and record when the Windows baseline is stable and which documented exclusions, if any, remain. End the informational rollout with an explicit maintainer decision to make the stable Windows check required, rather than leaving it informational indefinitely. Repository changes and any administrator-owned ruleset activation are distinct consented actions, not permissions granted by filing this issue.
• Document the resulting verification boundary: local focused RED/GREEN for iteration; hosted CI as the primary broad integration venue; platform-specific failures remain actionable within their tested scope. Remote location alone is not proof of coverage or correctness.

Non-goals for this issue publication: no workflow/source/test edits, installations, test reruns, assignee selection, status approval, ruleset changes, ready/queue/merge actions or additional issue creation. This is one central future-work tracker; implementation follows the normal issue-first approval workflow.