Follow-up to #5323, which added a `windows-latest` leg to the unit-test matrix. GitHub's Windows runner images set `core.autocrlf=true` globally and this repo declared no attributes, so as of that PR the two legs no longer test the same bytes: every text file arrives LF on Linux and CRLF on Windows.

Several specs read tracked source files and parse them as text. source-code-image-action.spec.ts and search-prefill.spec.ts read a .vue, compile it, then split the output on '\n' to strip import lines; empty-state-button-contrast.spec.ts regex-matches the components' scoped CSS and the theme stylesheets to pull custom-property names. They pass on Windows today only because those particular patterns happen to tolerate a trailing '\r'. The next assertion that does not — an `m`-flagged `$`, which will not match before a `\r\n`, a `toBe` on a split line, a snippet holding a literal '\n', a snapshot — goes red on Windows alone, with a cause that is invisible in a diff and unreproducible on macOS or Linux. test/unit/markdown.ts already carries an explicit `.replace(/(?:\r\n|\n)/g, '\n')` from the last time this cost someone an afternoon; that fix was local to one helper and left the class open.

`* text=auto eol=lf` normalizes on commit and checks out LF everywhere, closing the class in one line, and keeps a Windows contributor's editor from turning a whole file into a diff on save. Nothing in the tree needs CRLF: there are no .bat, .cmd or .ps1 files, and the single NSIS include, packages/desktop/build/windows/installer.nsh, reads LF fine.

Two vendored Open Sans licence texts had been committed with CRLF, so their blobs no longer matched what git would store for the same working-tree content; left alone they surface as spurious modifications the first time git compares by content rather than by stat cache. `git add --renormalize` fixes both, and the change is CR-at-EOL only — `git diff --ignore-cr-at-eol` across it is empty, no blob in the tree now contains a CR at end of line, and the working tree is clean.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Follow-up to #5323, which added a `windows-latest` leg to the unit-test matrix.

The job sets no `timeout-minutes` and so inherits GitHub's 360-minute default, unlike muya-spec.yml (15) and muya-e2e.yml (20); it was simply never given one back when it was a single 56-second Linux job. It now also runs on Windows, the platform where a worker that never exits is most plausible — an unreleased file watcher or an EBUSY rename, the same fs semantics that already force `it.skipIf(process.platform === 'win32')` in write-file-atomic.spec.ts.

One hang would leave `test (windows-latest)` pending for six hours while `fail-fast: false` lets the Linux leg report green beside it, which reads as a slow queue rather than a failure; it would hold a runner from a concurrency pool shared with every other PR, and `cancel-in-progress` frees it only once someone pushes to the same branch again.

Ten minutes turns that into a clear red check, and is four times the slowest run observed so far (2m25s on windows-latest, 56s on ubuntu-latest).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>