Stabilize frontmatter hash across LF/CRLF newline conventions

[davidahmann]

Problem

Cross-platform contributors can generate different frontmatter-hash values for semantically identical workflows when line endings differ (LF vs CRLF), causing noisy lock diffs and reducing trust in deterministic compile output.

Why Now

Mixed macOS/Linux/Windows workflows are common in active repos, and hash drift adds recurring review friction in CI lock-file updates.

Current Behavior Is Insufficient

Hash generation should be content-semantic, but newline-representation differences can leak into hash inputs in some frontmatter/import merge paths.

Why Code Change

This needs canonicalization in hash construction and regression tests; docs/policy cannot enforce contributor editor settings reliably.

Scope / Codepaths

• pkg/parser/frontmatter_hash.go
• pkg/parser/frontmatter_hash_consistency_test.go
• pkg/cli/hash_command.go

Acceptance / Validation

• Add regression tests that assert LF and CRLF variants produce identical hash values.
• Keep existing deterministic behavior for same-content same-newline inputs.
• Validate via parser/hash unit tests and repo-required checks.

Repro Evidence Packet

• Version/commit under test: origin/main as of 2026-02-20.
• Environment: macOS (Darwin), Go toolchain from repo setup.
• Minimal repro:
  1. Create two equivalent workflow files differing only in newline convention.
  2. Compute hash for each via parser hash path.
• Expected: identical hash.
• Actual: hash differs in at least one merge/string path (to be locked by test and fixed).

[pelikhan]

Excellent finds! Keep it coming!