[aywrite]

Two tests in scripts/tests/test_build_strategy.py fail on a windows
checkout. They have been failing for a while rather than recently: the
Scripts workflow runs on ubuntu only, so nothing in ci ever ran them on
windows.

The converter pins its source by the sha256 of the bytes on disk. The test
helper wrote the fixture with write_text and then hashed the string it had
just written. On linux those are the same bytes. On windows write_text
translates every newline into a carriage return and a newline, so the file
on disk is not the file the pin was taken over, and the script refused its
own fixture.

Write the encoded bytes, and take the pin over the same bytes.

What this is not

The first reading of this was a line ending problem in the checkout, to be
fixed with a .gitattributes rule over the fixture paths. It is not. The
fixture is built in tmp_path at run time, and the real suite is downloaded
rather than committed, so no .gitattributes rule reaches either one. No
test hashes a file that comes out of git. build_strategy.py was also not
at fault: it already writes its output with newline="\n".

The sentence in docs/DEVELOPMENT.md about scripts being checked out with
unix line endings is about the shell scripts, for the wsl route, and
*.sh text eol=lf delivers that. It reads as though it covers the python
scripts too, which is what sent the first reading down the wrong path, but
the rule matches the claim and needs no change.

Checks

• python -m pytest scripts/tests on windows: 215 passed, 52 skipped
• python3 -m pytest scripts/tests/test_build_strategy.py on linux: 26
  passed, so the change is a no-op there
• ruff check and ruff format --check clean

🤖 Generated with Claude Code

[github-actions]

Speed against 4016b1ee

Both sides built and run on this runner in this job, the way
scripts/speed.sh measures a perf commit. The change is between
medians, and the spread beside it is what the change has to be
read against. The node counts are the search's: they move when
the search does, and a speed change leaves them alone.

round     base nps  candidate nps
    1     12093002       12059267
    2     12091075       11938517
    3     12007693       11958961
    4     12096746       12137693
    5     11415096       10853520
    6     12199349       12028936
    7     12240724       12178957
    8     12194004       12230393
    9     12205622       12210052

             nodes    time  median nps  fastest nps
base       3868987  0.32 s    12096746     12240724
candidate  3868987  0.32 s    12059267     12230393
change                           -0.3%        -0.1%

the change is inside the spread, so the medians make no claim; the
fastest column is the steadier comparison when the machine was not
quiet

Speed: -0.3% (bench nps, 9 interleaved rounds vs 4016b1ee, spread 11.4%)