fix(frontmatter): silence yaml collection-key warning on template notes

[AlexMost]

What

Reading a note whose frontmatter contains a Templater placeholder — e.g. date: {{date}} — no longer spams stderr with:

Warning: Keys with collection values will be stringified due to JS Object restrictions: "{ date }". Set mapAsMap: true to use object keys.

Why

{{date}} is valid YAML flow syntax that parses to a collection-valued key (a map used as a map key). When yaml materializes that to a plain JS object it can't keep an object as a key, so it emits the warning via Node's process.emitWarning — once per such note, on every read/scan. Harmless to behavior, but it clutters the MCP server's stderr log.

Reported from a 12.1.0 → 13.0.0 field upgrade: fires on every template note whose frontmatter carries a {{…}} placeholder.

Fix

Pass logLevel: 'error' to parseYaml in splitFrontmatter (src/lib/obsidian/frontmatter.ts). This gates yaml's warnings while still throwing on genuinely malformed YAML, which the existing try/catch already handles. The parsed result is byte-for-byte unchanged — only the log noise is gone.

Not changed: mapAsMap: true (the library's own suggestion) would turn every frontmatter mapping into a JS Map, breaking the tool contract — rejected. The parseDocument mutate path in fs-vault-provider.ts re-serializes via toString() and never hits toJS() for these notes, so it doesn't emit the warning.

Test

Added a splitFrontmatter case that spies on process.emitWarning while parsing date: {{date}} frontmatter and asserts zero calls (red before the fix, green after), plus that parsing still succeeds.

npm test (819 passed), npm run lint, npm run typecheck all green.

🤖 Generated with Claude Code