Round-5 review found a sixth bypass, same mechanism as round 4's CRLF gap, one layer earlier: a leading UTF-8 BOM (EF BB BF) defeats strings.HasPrefix(doc, "---\n") before CRLF normalization even applies. Judged live-plausible rather than exotic — Notepad's default "UTF-8" save and PowerShell's pre-v6 Out-File/Set-Content both emit a BOM — so fixed inline at the same cost as the CRLF fix rather than deferred wholesale to hyperguild#138. Strip the BOM before the CRLF normalization in frontmatterBlock, so every caller (fence-presence detection and frontmatterScalars) agrees regardless of encoding. Drawing the line here: further encoding variants in this family (NEL line separators, UTF-16 BOM, lone-CR classic-Mac endings) are judged not live-plausible in a git-tracked UTF-8 markdown corpus and are tracked wholesale under hyperguild#138's parser consolidation rather than chased as individual rounds on this PR. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>