fix(build): force LF line endings for shell scripts

[mlandolfi90]

On Windows, git's default core.autocrlf=true checks out every .sh with CRLF endings. The Docker cross-build then fails at clean-c: bash cannot source scripts/path-safety.sh ($'\r': command not found), and the same applies to every script under scripts/ and tests/.

Declaring *.sh text eol=lf in .gitattributes keeps checkouts LF on all platforms regardless of local git config. One-line fix, no renormalization needed — the index already stores LF.

Hit today on a fresh Windows clone while building from main.

🤖 Generated with Claude Code

[DeusData]

Thank you for the contribution and for reporting the Windows checkout failure from a fresh build. This is now triaged as a high-priority Windows build bug for 0.9.1-rc. It overlaps #1272, so both approaches will be considered together during review. Our community PR queue is currently quite full, so it may take a little time before we can complete that review. We are doing our best to support community contributions and will return with code-grounded feedback as capacity opens.

[DeusData]

Thank you for this — and I want to be straight with you about where it stands, because the honest answer is "your diagnosis was right, and we are likely to take someone else's PR for it."

Your bug report is the best part of this PR. The exact failure signature ($'\r': command not found from clean-c sourcing scripts/path-safety.sh), the exact cause (core.autocrlf=true on a default Windows install), from a real fresh clone — that is immediately reproducible and actionable, which is rarer than it should be. And your claim that no renormalization is needed checks out precisely: I verified that zero tracked .sh files contain CRLF in the index, so the attribute lands with no churn at all. That diligence is appreciated.

I also confirmed the underlying gap is real and still open: main's .gitattributes currently holds only linguist and diff attributes for vendored grammars, with no eol or text rules whatsoever.

Why the other PR. #1272 (@xumian520) carries the identical *.sh text eol=lf line, plus two things yours does not:

• explicit rules for scripts/git-hooks/commit-msg and scripts/hooks/pre-commit — which I verified are the only two extensionless shell entrypoints in the whole tree, and which the *.sh glob cannot match. A Windows contributor's commit-msg DCO hook checking out as CRLF is the same bug you hit, one layer down;
• a regression guard wired into our step-0 contract slot, dynamic over git ls-files, so it fails closed if anyone ever removes the attribute.

So it is a strict superset rather than a competing approach — there is nothing in your change that it misses.

I am deliberately leaving this open rather than closing it now. #1272 currently conflicts with main and needs a rebase, and I would rather not close the working PR before the superset actually lands. If that rebase does not happen, yours is the fallback and we will take it. Either way you will get a clear answer rather than silence.

One thing worth knowing: the two failing checks on your PR are not your fault. They are a daemon startup flake from an older base, since fixed on main by #1320. Nothing in a .gitattributes change could have caused them, and I did not want that sitting on your PR looking like a defect.