fix: remove a stray CR byte from .gitattributes

The previous commit wrote a literal carriage-return byte into a comment, where
the text was meant to show the two characters backslash-r. Git's content sniffing
treats a lone CR as a sign of binary data, so .gitattributes itself was classed
-text (git ls-files --eol reported i/-text): the one file in the template that
the new LF policy could not normalise, and one every repo created from it would
have inherited.

The rules themselves were never affected - the byte sat inside a comment.

The comment now says "a trailing CR byte" in words. .gitattributes reports
i/lf w/lf, and `git add --renormalize .` stages nothing else.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LU1NRL7fAaZTtFMTTPn2b1

.gitattributes

@@ -5,7 +5,7 @@
 # that setting, so a fresh clone gets LF regardless of how its machine is set up.
 #
 # It matters beyond tidiness. tools/branding-sites.tsv is read line by line with
-# `read`, and under CRLF every row's last field gained a trailing 
+# `read`, and under CRLF every row's last field gained a trailing CR byte - so the
 # branding checker reported all 29 sites as missing on Windows while passing on the
 # Linux CI runner. text=auto leaves genuinely binary files alone.
 * text=auto eol=lf