With FrontmatterNaming.AsIs, merging still renames a lone list property to its canonical key (e.g. section: list becomes categories:) #147

What's wrong

In Frontmatter/PropertyMerger.cs, a group of keys that share one canonical name is written back in one of two ways:

• Scalar values keep the original key: target[originalKeys[0]] = firstValue (around line 165).
• List values go through MergeArrayValues, which always writes target[canonicalKey] = ... (around line 189). This happens even when the group has only one key and nothing is merged.

So list properties get renamed during merging, whatever FrontmatterNaming the caller asked for. Renaming is meant to be NameStandardizer's job, and FrontmatterNaming.AsIs is meant to turn it off.

Failure scenario

Frontmatter.CombineFrontmatter(
    "---\nsection:\n  - news\nsummary: hi\n---\nBody\n",
    FrontmatterNaming.AsIs, FrontmatterOrder.AsIs, FrontmatterMergeStrategy.Conservative);

• Actual: the output header contains categories: [news].
• Same document with section: news (a scalar): the key stays section.
• Expected: with AsIs naming, a key that isn't merged with anything keeps its name.

This matters for site generators where the key name has its own meaning. Hugo's section is one example. Content can silently move to a different taxonomy. keywords becomes tags and category becomes categories the same way.

I reproduced this with an MSTest test against the current main.

Suggested fix / acceptance criteria

• When originalKeys.Count == 1, copy the key and value through unchanged, the same as the scalar branch does.
• When several list-valued keys really are merged, decide on one target key and use it consistently. Either use originalKeys[0] to match the scalar branch, or use the canonical key only when naming is not AsIs.
• Add a test: a lone list property with AsIs naming keeps its key under every merge strategy.