Windows: decide what `python -m cw.testing parity` means on the Windows runner

[thorwhalen]

pyproject.toml:130 is test_on_windows = true. The definition of v1 is a harness that
asserts byte-identical stdout/stderr against goldens recorded on a developer machine.
That fails on \r\n alone, before you reach cp1252 console encoding, .exe console-script
shims, and shlex.split — which the spec concedes is POSIX-only and then offers "the list
form of prog" as the Windows path, which is not the format read_cases parses.

Nothing in the research programme states which way this goes. Decide it before the gate is
written, or the gate is red on a third of the matrix on day one.

Options

• A. Normalise: goldens store \n-normalised text; comparison normalises newlines and
  forces PYTHONIOENCODING=utf-8 + COLUMNS in the subprocess env. Parity runs everywhere.
• B. Exempt: the parity job is if: runner.os != 'Windows', and the definition of v1 is
  explicitly "parity on POSIX; import + unit tests on Windows".

Recommendation: A, with the newline decision made in the goldens issue so it is baked into
the format rather than bolted onto the comparator. read_cases must accept the list form of a
case so Windows never needs shlex.

Acceptance criteria

• Decision recorded in the parity module's docstring and the ADR index.
• If A: cw.testing.normalise_usage and the tier-1 comparator both newline-normalise; a
  test feeds \r\n golden text and passes.
• If A: read_cases parses both a shlex line form and a JSON list form; a test covers
  both.
• If B: pyproject.toml's test_on_windows and the CI matrix are edited to match, and
  the README says what v1 means on Windows.
• Whichever: cw's CI is green on all three OSes at M3.

Depends on

• cw.testing: the standalone characterize/replay harness (D4) #5 — cw.testing: the standalone characterize/replay harness (D4)

---

Research & rationale: the canonical spec and the full fleet audit live in the private research ledger (https://github.com/thorwhalen/priv/discussions/65). Effort: small.

[thorwhalen]

Closed with #33, and — for the first time — actually observed, not just configured.

Every previous phase reported decision A ("normalise") as implemented and unit-tested on macOS, with the Windows leg unverified because nobody had a Windows runner. The first CI run on build-v1 found three real Windows failures, all latent before this branch:

• cw.testing._as_command split the command string with POSIX shlex, which eats the backslashes out of C:\py\python.exe and leaves a command nothing can run. It surfaced as FileNotFoundError: [WinError 2] with no clue where it came from — exactly the "the likely culprit is the subprocess round-trip, not parity" that the testing phase's handoff predicted. Fixed with non-POSIX splitting on os.name == 'nt' (stripping the quotes that mode keeps), plus four tests pinning both platforms including a quoted path with a space.
• cw.resolution.resolve_func_from_dot_path's doctest asserted os.path.join('a', 'b') == 'a/b'.
• Two grammar doctests relied on NORMALIZE_WHITESPACE, which wads' CI drops (-o doctest_optionflags='ELLIPSIS IGNORE_EXCEPTION_DETAIL', unconditionally) — a POSIX failure too, and the one that took both Linux legs down with it.

Green on all three OSes now:

ci / Validation (3.10)   pass
ci / Validation (3.12)   pass
ci / Windows Tests       pass

parity itself was never the risk: it spawns no subprocess at all, so the .exe console-script shim and the cp1252 console never enter the picture. The risk was the half of cw.testing that a migrating repo actually runs.