What happened?

parseMarkdown (in src/core/markdown.ts) raises a MISSING_CLOSE validation error on a file whose YAML frontmatter
starts with one or more # comment lines, even when the closing --- is present. The cause is the scanner at lines
~219-248: it walks the lines after the opening --- and records the first ^#{1,6}\s-shaped line as
headingBeforeClose. When the closing fence is later found, the scanner still flags the recorded "heading" as a
MISSING_CLOSE finding with the message Heading at line N found inside frontmatter zone (closing --- comes after). The
line is a perfectly valid YAML comment, not a markdown heading.

YAML permits # comments anywhere outside string scalars, so a leading-# line inside the fence is a comment by
definition. The heading-shape heuristic was meant to catch unclosed frontmatter; using it inside a fence that DOES close
is the false-positive.

What did you expect?

The parser should accept the file (no MISSING_CLOSE finding) when the closing --- is present, regardless of #
comment lines that appear between the fences.

Steps to reproduce

Create a markdown file with YAML comment lines at the top of its frontmatter:

---
# Research Template
# This file serves as a template for all research findings
research_id: "R19"
title: "iOS App Clip security limitations"
---
body

Run bun test --bail test/markdown-validation.test.ts against a test that calls parseMarkdown(md, undefined, { validate: true }) on the content above and asserts the errors list does not contain MISSING_CLOSE. With current
master at 4ee530f3 (v0.42.42.0), the assertion fails. The errors list contains a MISSING_CLOSE with the message
Heading at line 2 found inside frontmatter zone (closing --- comes after).

Environment

• gbrain version: master at 4ee530f3 (v0.42.42.0)
• OS: Linux
• Bun: 1.3.14
• Database: not relevant (the bug is in pure string parsing; no engine state involved)

gbrain doctor --json output

Not material, because the bug is in src/core/markdown.ts:collectValidationErrors and reproduces against unit tests
without any engine state. The bug-report template's doctor-output paste block is included for completeness:

(omitted — reproducible without a connected engine)

Adjacent context

• v0.37.5.0 (v0.37.5.0 fix(markdown): YAML-aware NESTED_QUOTES validator (stops flagging valid YAML) #1229 ) fixed the same parser's NESTED_QUOTES validator to stop flagging valid YAML: direct precedent for
  this fix's shape. The proposed fix in the paired PR follows the same "stop the false positive without weakening the
  genuine-error path" pattern.
• frontmatter audit: false-positive MISSING_OPEN on convention plain-markdown files (CHANGELOG, README, CONTRIBUTING, LICENSE, test fixtures) #1074 (frontmatter audit: false-positive MISSING_OPEN on convention plain-markdown files) is the closest open
  neighbor: same parser, different error code, same class of false-positive. The two fixes are independent and
  non-conflicting.

Proposed fix

When walking lines between the opening --- and the closing ---, do NOT track a headingBeforeClose. Once the
closing --- is found, content between the fences is YAML by definition; # lines are comments. The heading hint
remains valuable in the genuine-missing-close branch (still surface the first heading-shaped line so the error message
points the user at the right line). Paired PR ready to open; see feat/frontmatter-yaml-comments on
brettdavies/gbrain.