bug(windows): website homepage rejects CRLF frontmatter

[knqiufan]

Describe the bug

The website's English and Chinese homepages reject valid YAML frontmatter when the checked-out Markdown files use CRLF line endings. A Windows checkout with core.autocrlf=true encounters this without editing the document content.

getHomeContent() reads the source as UTF-8 but requires it to start with ---\n before invoking the YAML parser. ---\r\n fails this check and is reported as missing frontmatter. The homepage source files are not assigned an LF-only rule in .gitattributes.

Steps to reproduce

1. Check out master 80d618bd61432d1bb4eae85433fa22f2bbd50bce on Windows with core.autocrlf=true. Confirm that docs/en/index.md and docs/zh/index.md begin with the bytes 2d 2d 2d 0d 0a.
2. Install the website's pinned dependencies with pnpm --dir website install --frozen-lockfile.
3. From website/, save the following as probe-home.mts and run pnpm exec tsx probe-home.mts:

import { getHomeContent } from './src/lib/home-content.ts';

for (const locale of ['en', 'zh'] as const) {
  try {
    await getHomeContent(locale);
    console.log(locale, 'ok');
  } catch (error) {
    console.error(locale, error.message);
  }
}

This calls the same loader used by the homepage and isolates this failure from any earlier link-validation failure in pnpm build.

Expected behavior

Equivalent LF and CRLF Markdown documents yield the same homepage data. A present frontmatter block should not be reported as missing solely because of its line endings.

Normalize line endings before locating and slicing the frontmatter, or use a frontmatter parser that accepts both forms. Preserve meaningful errors for genuinely absent or malformed frontmatter. Check the analogous delimiter checks in content generation, and cover English and Chinese inputs with both newline styles.

Actual behavior

Both real checkout files fail with:

Home frontmatter is missing in .../docs/en/index.md
Home frontmatter is missing in .../docs/zh/index.md

A control experiment called the unmodified getHomeContent() against temporary copies of the same documents: both LF copies succeeded, while both CRLF copies failed. This prevents home rendering/static export on affected Windows checkouts; the Linux documentation CI does not expose it.

Environment

• Upstream master: 80d618bd61432d1bb4eae85433fa22f2bbd50bce.
• Windows x64, Node.js 24.14.1, pnpm 11.13.1, locked website dependencies.
• git config core.autocrlf: true.
• No corresponding open issue or implementation PR was found in the repository's open items or changed files.
• AI assistance: OpenAI Codex assisted with source inspection, LF/CRLF control experiments, and this report.

Are you willing to submit a PR to fix this bug?

• Yes, I would like to submit a PR.