Stale identity guard rejects allowed matches on Windows CRLF output

Description

The root stale-identity guard parses git grep output by splitting only on "\n", then requires its line regex to consume the entire string. On Windows, git grep emits CRLF, leaving "\r" on every split line.

The regular expression does not consume that trailing carriage return, so the parser treats allowed legacy-cleanup matches as unparsed/unexpected. The final line happens to pass only because the preceding global .trim() removes its last "\r".

Code reference

• rules/ast-grep/stale-identity.test.ts:10-15 enumerates four exact allowed cleanup matches.
• rules/ast-grep/stale-identity.test.ts:30-35 trims the complete output once, splits on "\n", and anchors the parser regex at the end of each remaining CRLF line.
• rules/ast-grep/stale-identity.test.ts:36 returns an unparsed line as unexpected.
• rules/ast-grep/stale-identity.test.ts:37-38 would correctly trim the captured contents, but the first three Windows lines never reach that comparison.

Reproduction

On Windows with Git configured to produce the repository's normal CRLF output:

.\node_modules\.bin\vitest.CMD run rules/ast-grep/stale-identity.test.ts --reporter=verbose

The test fails with three supposedly unexpected matches:

packages/sdk-python/scripts/build.py:18:        "stagehand_v4-*.whl",\r
packages/sdk-python/scripts/build.py:19:        "stagehand_v4-*.tar.gz",\r
packages/sdk-python/tests/test_build.py:12:        "stagehand_v4-0.1.0-py3-none-any.whl",\r

The fourth allowed match is the last output line and passes because stdout.trim() removes its trailing carriage return.

Expected behavior

All four explicitly allowed legacy cleanup strings should be ignored regardless of whether git grep uses LF or CRLF.

Actual behavior

Three allowed entries are reported as forbidden identities on Windows, failing the root test gate.

Why it matters

This guard is part of the repository-wide tests. A line-ending artifact makes the gate deterministically fail for Windows contributors and distracts from actual stale-package identity violations.

Duplicate/history check

I searched open and closed issues and PRs for stale-identity, CRLF handling, git grep parsing, and the legacy package identity. PR #2497 introduced the guard and PR #2730 currently extends a neighboring AST regression test, but neither addresses CRLF parsing. I found no prior report for this failure.