CombineFrontmatter deletes a frontmatter block it cannot parse when another block does parse #139

What's wrong

ExtractFrontmatterObjects (Frontmatter/Frontmatter.cs:~330-338) skips any block that fails YamlSerializer.TryParseYamlObject, but it still returns the body from after all the blocks. CombineFrontmatter (:78-114) then writes a header built only from the blocks that parsed, followed by that body. The text of the unparseable block is dropped from the document.

When every block fails to parse, frontmatterObjects.Count == 0 and the input comes back unchanged. Data is lost only in the mixed case.

Repro

Frontmatter.CombineFrontmatter("---\ntitle: T\n---\n---\nkey: [unclosed\n---\nbody\n");

• Actual: ---\ntitle: T\n---\nbody. The second block, key: [unclosed, has been deleted.
• Expected: the document returned unchanged, or the unparseable block preserved verbatim.

Why it matters

A hand-edited file with one malformed block loses that block's content the first time a tool normalises it, and the caller gets no error. AddFrontmatter already treats unreadable frontmatter as "leave it alone" (commit 2b3bad8). CombineFrontmatter is the sibling path that was missed.

Suggested fix

Have ExtractFrontmatterObjects report whether any non-blank block failed to parse; for example, return false or expose a flag. In that case CombineFrontmatter should return (and cache) the input unchanged, matching AddFrontmatter's guard.

Acceptance: the repro returns its input unchanged, with a regression test.