fix: Windows portability for os.chown and git-apply CRLF hermeticity

[KNambiarDJsc]

Summary

Two of the mechanical root causes from the #130 Windows-portability triage (#2 and #4):

#2 — os.chown doesn't exist on Windows. grade.py's two call sites now guard on sys.platform. Both only ever run for real inside the Linux verifier container regardless of host OS (every other path in that module is an absolute container path like /workspace, /tests), so the guard changes no production behavior — it only lets the tests that call validate_submission() directly run on a Windows host. Four test files monkeypatch.setattr("os.chown", ...) to neutralize the call during unit tests; switched to raising=False so the patch itself doesn't AttributeError on a platform where the attribute never existed.

#4 — git apply --reverse isn't hermetic against the caller's git config. reverse_source() and reverse_crlf_patch() both run git apply against plain directories (not git repositories), so without an explicit override they silently inherit the caller's global git config. On a machine with core.autocrlf=true — the Git-for-Windows installer default — git apply was rewriting LF to CRLF while applying, corrupting the exact-byte reversal both functions promise and breaking the dedicated reverse_crlf_patch() fallback, which assumes the applied bytes are exactly what it constructed and verifies that via git blob hashes. Both invocations now pass -c core.autocrlf=false explicitly.

While tracking that down I also found two write_text() calls doing the same kind of damage independently of git apply: the reversed patch file (reverse_source()) and the private verifier test source (construct()) are both read back later as raw bytes, but were written with write_text(), whose newline translation rewrites \n to the host line separator on the way in. Switched both to write_bytes().

Also skips test_verifier_editor_backups.py's "fifo" parametrize case on win32: os.mkfifo has no Windows equivalent at all, so that one case can't run there (not a permissions issue like the neighboring symlink cases, which are left alone — those need your call on whether Developer Mode is a documented prerequisite, per my earlier comment on #130).

Test plan

• uv run ruff check / ruff format --check on all touched files — clean.
• Windows 11, full suite before/after: 249 failed, 97 errors → 242 failed, 74 errors (net -30). Grepped the full run for any remaining os.chown / os.mkfifo / CRLF-patch-apply failures — none; the only matches left are my own guard code and the one intentional skip.
• Linux (WSL Ubuntu, uv sync --group dev --all-extras --frozen + uv run --all-extras pytest -q, matching CI): 1871 passed, 0 failed — including the fifo and symlink cases this skip doesn't touch on that platform.
• The 7 Windows failures remaining in the files this PR touches are all the already-tracked symlink-privilege issue (WinError 1314, root cause pr_runtime pipeline (v0.3): SWE-bench-style PR mining with sandbox-verified oracles #3 in Track native Windows controller and artifact portability #130) — untouched here, pending your decision on documenting Developer Mode as a prerequisite.

Out of scope

Root cause #1 (emitter/bundle.py's mode-check tied to the bundle's content-addressed integrity hash) and root cause #3 (symlink privilege) — both flagged in my correction comment on #130 as needing your design/product decision, not something to ship unilaterally as a platform guard.

Closes part of #130.

[adithya-s-k]

Thanks, tested and merged. Reproduced the autocrlf issue and confirmed the fix. Keeping #130 open for the remaining Windows work.