ci: add line-endings check as a parallel verify job

[joaodinissf]

Summary

Adds a new line-endings job to verify.yml that runs in parallel with pmd, checkstyle, and maven-verify. It uses git ls-files --eol to check every text file in the index is stored as LF, exempting .bat/.cmd/.ps1 (the exceptions that .gitattributes keeps on CRLF for Windows compatibility).

A second layer of defence on top of the normalization filter introduced in #1314.

Why a second layer?

Git's clean filter (driven by .gitattributes: * text=auto eol=lf) normalizes text files at commit time. Two gaps slip through:

1. Miscategorization. text=auto uses a null-byte heuristic to decide if a file is text. A text file with an early null byte (rare but possible — certain XML CDATA blocks, certain encoded configs) is treated as binary and not normalized. CRLF sneaks in unchanged.
2. Filter bypass. A --literally commit or a custom hook path can skip the filter.

Neither is common, but both are silent. This check surfaces them before they matter.

Depends on

Depends on #1314 landing first so the repo is actually LF-clean when this check starts enforcing. Opened on top of lf-normalize branch content.

Verification that the check catches real violations

A test commit with a CRLF file pushed onto this branch (subsequently removed) showed the job correctly flagging the file:

Files with CRLF/mixed line endings stored in the index:
i/crlf  w/crlf  attr/text=auto eol=lf   test-crlf-should-fail-ci.txt
##[error]Process completed with exit code 1.

Job completed in ~5s. Git's own clean filter caught the first attempt (writing a CRLF file through normal git add); bypassing the filter required git hash-object --no-filters + git update-index --cacheinfo, simulating a real filter-bypass scenario.

🤖 Generated with Claude Code