chore: normalise line endings to lf and enforce it

[marc0olo]

Makes LF the line ending everywhere, and stops it drifting again.

Why

Line endings differed per file and per repository, so an edit made on Windows — or by any tool that normalises newlines — silently rewrote a whole file. That turned a 29 line README change into a 273 line diff, and a 101 line change to BaseCache.java into a 459 line diff. A diff that size cannot be reviewed and makes a commit look far riskier than it is.

Three parts, because none of them is enough alone

.gitattributes normalises on git add, so a contributor's core.autocrlf cannot put CRLF into the index. Extensions are listed explicitly rather than relying on text=auto alone — event-processor-contract has carried a * text=auto eol=lf rule since its own line ending PR and still had a CRLF .gitignore and a mixed README.md, so the heuristic is not something to depend on. *.bat and *.cmd keep CRLF, because cmd.exe wants it.

git add --renormalize ., in this commit, for what is already committed. Adding the attributes does not retroact — that is precisely how those two files kept their CRLF for years.

A CI check, which is the actual guarantee, in .github/workflows/validate.yml:

if git ls-files --eol | grep -E '^i/(crlf|mixed)'; then
  echo '::error::the files listed above have CRLF or mixed line endings in the index'
  exit 1
fi

git ls-files --eol reports what is in the index, not the working tree, so it cannot be fooled by a local checkout and it names the offending files. This is what turns the convention into enforcement.

.editorconfig is there so an editor does not fight the attributes in the working tree.

This commit

55 files changed, 2261 insertions(+), 2166 deletions(-), of which 52 are line endings only.

Verified with git diff --cached --ignore-cr-at-eol --stat before committing: apart from the files this commit adds, nothing changed but line endings. Worth reproducing on the merge commit rather than reading 251 files —

git show --ignore-cr-at-eol --stat HEAD    # only .gitattributes, .editorconfig and the workflow
git ls-files --eol | grep -E '^i/(crlf|mixed)'   # empty

After merging

Working copies keep their old CRLF until the files are re-checked-out — eol=lf applies on checkout and git will not rewrite files it considers unmodified. Nothing breaks, and the next git add normalises anyway, but to refresh a clone in one go:

git rm --cached -r -q . && git reset --hard

Untracked files are not touched by either command. Afterwards mvnw.cmd is the only file left with CRLF in the working tree, which is intended.