The nightly writes SHA256SUMS.txt with CRLF too

[erikdarlingdata]

#2384 fixed build.yml and left the identical step in nightly.yml, so every nightly since has published a checksum file that shasum -c cannot read.

Found while auditing what in 3.5.1 is verified by anything other than reading the diff — this one is only exercised by actually running the pipeline, so I checked the published artifact:

$ file nightly_SHA256SUMS.txt
ASCII text, with CRLF line terminators

$ head -1 nightly_SHA256SUMS.txt | cat -v
f27860c5...  PerformanceMonitorDarling-3.5.0-nightly.20260821.zip^M

And with the artifact present, so the failure is the trailing CR rather than a missing file:

CRLF  ->  shasum: artifact.zip: No such file or directory
          artifact.zip: FAILED open or read
LF    ->  artifact.zip: OK

The nightly is the worse of the two to get wrong. It is a prerelease, so whoever downloads it is disproportionately likely to check a hash by hand — and FAILED open or read is exactly what a tampered download looks like.

Same fix as #2384. Both copies now carry a note that the other exists, since the whole defect was one being updated without the other.

[claude]

Reviewed. This is a clean, minimal fix — the nightly checksum step now matches build.yml's [IO.File]::WriteAllText approach byte-for-byte (explicit LF, no BOM), and both files got a cross-reference comment pointing at their twin, which directly addresses the root cause (one copy was fixed in #2384, the other wasn't). Confirmed there's no third copy of this step anywhere in .github/workflows/ — the Linux checksum path (sha256sum in a separate step) never had the CRLF problem since it isn't PowerShell/Out-File, so it's correctly left untouched. No T-SQL, no Lite/Darling app parity concerns (CI-only change), no security implications. LGTM.