test: make suite portable on Windows

[innovationty]

What this changes

Skips the POSIX executable-bit assertion on Windows, where NTFS cannot
represent that behavior, while leaving both assertions unchanged on POSIX.
Generated tutorial fixtures and artifacts are now read and written explicitly
as UTF-8 instead of relying on the Windows locale.

Why

On this Windows checkout, the baseline had 11 failures: one synthesized
executable-bit failure and ten GBK/UTF-8 decode failures. The test-only fix
keeps the product code and POSIX behavior untouched.

Validation

• Before: 11 failed, 350 passed
• After: 360 passed, 1 skipped on Windows; the skip is the POSIX-only permission check
• python -m ruff check src/ tests/

No Docker, API keys, source files, sandbox flags, or prompts were involved.

Fixes #144

[alphacrack]

Thanks @innovationty — this is a model first PR for this repo.

What I checked, so you know the bar you cleared:

• Skip vs. weaken: the skipif gates only on os.name == "nt" and the S_IXUSR/S_IXOTH assertions are untouched, so POSIX still asserts the real product behavior (distill.write_commands_sh's chmod(0o755)). Exactly what #144 asked for.
• Encoding fixes: every bare read_text/write_text on generated artifacts in test_tutorial.py now pins encoding="utf-8", matching what the writers in tutorial.py produce — fixed rather than skipped, which is the right call for this class.
• Ran your exact head locally (macOS): 361 passed — identical to main, so the POSIX path is unaffected. ruff, mypy, and the coverage gate (85.99% ≥ 80%) pass too.
• The Regression (#144, reported in #82) docstring follows the house convention, and your Windows before/after numbers line up exactly with the failure split predicted in the issue — GBK verification is a nicer stress test than the cp1252 case I wrote up.

CI shows no checks only because first-time contributions need a maintainer to approve the workflow run — the maintainer will kick that off; expect green.

If you're interested in a follow-up, the windows-latest CI lane mentioned in #144 is the natural next step (comment there first — it's a runner-cost decision). Either way: a tight, well-validated diff. Thank you.