ci: add gate-line-endings — block new CRLF from entering the repo

[izzywdev]

Rolls out the org-wide gate-line-endings CI gate, added to the FuzeSDLC standard workflow stack in FuzeSDLC#73. Adds one workflow file; changes nothing else.

What it does

Blocks new CRLF from entering the repo.

event	behaviour
pull_request	hard fail, but only on files the PR adds/changes
push to default	reports any pre-existing CRLF as warnings — never blocking

So it needs no cleanup before merging: an existing CRLF backlog stays warning-only, and only newly introduced CRLF fails. Clean up whenever convenient with git add --renormalize .; the gate keeps it clean afterwards.

Why

A CRLF check-in has broken production in this org more than once:

• FuzeFront releases — the tag-bump awk anchors on line content; a CRLF values-prod.yaml made every $-anchored match miss, the count guard hit 0, and every release died until someone restored the endings by hand.
• A vendored OpenAPI contract — CI byte-diffs it against upstream; CRLF made every line differ, failing a drift gate for a file nobody had changed.
• CSS — PostCSS reports Unexpected } on balanced braces.
• Committed .sh — breaks at runtime on a \r that never appears in a diff.

.gitattributes does not close this: it only covers paths someone thought to list, and commits made through the GitHub Contents API (bots, agent runs, web edits) bypass it entirely. The gate inspects the index side of git ls-files --eol — the bytes actually stored in git — so it sees both.

Verification

The gate's bash was extracted verbatim from the workflow and exercised against a purpose-built repo: a PR adding a CRLF file fails and names it; a PR touching only clean files passes even with legacy CRLF present; push to default warns and exits 0; CRLF .bat (allowlisted) is not flagged.

Opened as part of propagating the standard stack — governance_sync cannot push .github/workflows/** itself (the default GITHUB_TOKEN lacks the scope), so standard-stack workflows arrive by PR.

🤖 Generated with Claude Code