Add .gitattributes so line endings cannot corrupt frozen hashes

## The problem Every commit on Windows prints a wall of warnings: ``` warning: in the working copy of 'memory/events.jsonl', LF will be replaced by CRLF the next time Git touches it ``` The repository has no `.gitattributes`, so line-ending handling depends on each contributor's local `core.autocrlf` setting. For a project whose canonical store is a byte-exact append-only JSONL file, and which hashes files into frozen review packets, inconsistent line endings are a genuine correctness risk rather than cosmetic noise. A contributor on a different platform could produce a file that is byte-different but semantically identical, invalidating a frozen SHA-256 for no real reason. ## The fix Add a `.gitattributes` that: - normalizes text files to LF in the repository; - explicitly marks `memory/events.jsonl` as LF, since it is the canonical append-only log; - leaves genuinely binary files untouched; - considers whether frozen fixture files under `data/lab/` should be pinned to LF as well. Please check whether any currently frozen hash would change as a result. If one would, say so in this issue rather than changing it — a frozen artifact must not be silently renormalized, and that case needs a separate decision. ## Acceptance criteria - [ ] `.gitattributes` exists and covers text, the canonical log, and binary files. - [ ] A fresh clone on Windows and on Linux produces identical `git hash-object` output for `memory/events.jsonl`. - [ ] The issue records whether any frozen hash in `data/lab/**/manifest.json` or `**/packet-manifest.json` would be affected. - [ ] `python scripts/verify_memory_integrity.py` still passes. ## Getting started No research background needed. Useful if you have dealt with cross-platform Git repositories before.