fix(guard): apply normalizeEol to packaged leaf boundary check (#6192)

[xxiaoxiong]

摘要

scripts/check-packaged-leaf-boundary.ts 用 String.prototype.includes 字节级比较 requiredWorkspaceUnitBlock 模板字面量和 .github/workflows/ci.yml。在 Windows (core.autocrlf=true) 下工作树读 ci.yml 带 CRLF，行尾是 \r\n，模板字面量用 LF (\n)，includes 永远 false，guard 误报 "ci.yml no longer contains the guarded … block"。

scripts/check-design-system-manifests.ts (#5176) 已经引入了 normalizeEol 但只是 inline 字符串替换。这个 PR 把 helper 提取到 scripts/lib/eol.ts，packaged leaf boundary check 也调它。

改动

• scripts/lib/eol.ts (new, 16 行) — normalizeEol(input: string): string，CRLF → LF。
• scripts/check-packaged-leaf-boundary.ts — import normalizeEol，.includes() 两边都过一遍。
• scripts/check-design-system-manifests.ts — 用 ./lib/eol.ts 的 helper，删掉 inline 替换。
• e2e/tests/scripts/eol-crlf-regression.test.ts (new, 63 行, 7 tests) — pin LF/CRLF 行为；CRLF haystack 原始 includes 失败，normalizeEol 后过。

验证

• pnpm guard: EXIT 0
• pnpm --filter @open-design/e2e exec vitest run tests/scripts/eol-crlf-regression.test.ts: 7/7 pass
• 基于 upstream/main (30501a2)，不引入 fork 独有改动。

不变量

• CI: 跟着 guard 的现有 PR check 走
• Scope: 只动脚本 + e2e test，不碰业务代码

Closes

• Windows: pnpm guard packaged-leaf check fails on a CRLF working tree (same root cause as #5175, different check) #6192

[lefarcen]

Thanks @xxiaoxiong — scoping this to the guard-side EOL normalization plus a focused regression test is a nice, tight follow-up to #6192.

I'll get the right reviewer and labels on it now.

[lefarcen]

Thanks for keeping the fix scoped to the guard path and for spelling out the Windows CRLF repro clearly.

Could you reshape the description so pool review can scan it faster with the current template — specifically add Why, What users will see, Surface area, and Validation as explicit sections.

Related: #6192 (issue context), #6195 by @jfpaezl (similar Windows CRLF guard fix touching the same boundary).

[nettee]

@xxiaoxiong I verified the CRLF guard fix end to end in the prepared worktree. The normalizeEol extraction keeps the existing design-system manifest behavior intact, applies the same normalization to the packaged leaf boundary check, and the focused regression test covers both the raw CRLF failure mode and the normalized success path.

I also reran pnpm guard and pnpm --filter @open-design/e2e exec vitest run tests/scripts/eol-crlf-regression.test.ts locally on this head, and both passed. Nice tight follow-up on the Windows false-positive case.

_{🔁 Powered by Looper · runner=reviewer · agent=codex · An autonomous AI dev team for your GitHub repos.}

[lefarcen]

Thanks @jfpaezl — that's useful context.

Understood that #6220 addresses the packaged-leaf includes() false positive, while #6195 is carrying the second CRLF-sensitive path in scripts/check-certain-exempt-consumption.ts. We won't treat this PR by itself as the full closure of #6192 while that second check is still outstanding.

And agreed on the helper shape — rebasing the remaining call site onto scripts/lib/eol.ts sounds like the cleanest next step.

[xxiaoxiong]

Heads-up for maintainers: this PR's ci workflow run (https://github.com/nexu-io/open-design/actions/runs/30435045516) has been queued for ~23 hours with no runner picking up the Static gate / Detect validation scopes jobs. The fork-pr-approval gate already passed (approve+label jobs done at 08:19-08:20 UTC). The branch is mergeable and the change is small (one commit, scoped to scripts/check-packaged-leaf-boundary.ts + tests). If the runner queue is genuinely stuck, re-triggering or kicking the runners would unblock merge.

[lefarcen]

Thanks for flagging this.

With reviewer approval already in place, this looks like runner availability / workflow queueing rather than anything still blocked on your change itself. We'll treat the stuck Static gate / Detect validation scopes jobs as CI infra state, not author-side follow-up, and keep the PR open while a maintainer re-runs or unsticks that workflow.