🐞 .gitattributes vs. content inconsistency

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Current Behavior

The electionguard-core2 repo's `.gitattributes` specifies eol=lf but the files were committed with CRLF. Thus, clones will be immediately dirty.

To remedy, make the specification agree with the contents. I propose that the right answer is to follow standard line ending conventions used the world-over for technical artifacts, which would mean fixing the files in the repository that were updated by someone on Windows that did not understand these kinds of things.

### Expected Behavior

_No response_

### Steps To Reproduce

_No response_

### Environment

```markdown
- OS:
```

### Anything else?

_No response_

Start by inspecting .gitattributes and the repository files it matches, then use Git to identify which tracked files have CRLF content despite the eol=lf rule. Done means the tracked files and attribute specification agree so a fresh clone does not immediately show line-ending changes.

Written by the indexing model from the issue text.