write_note overwrite: server merge-preserves unrecognized frontmatter keys but the tool documents replacement — and content-carried frontmatter, malformed-base discard, and tag regeneration still lose keys silently #1653

Bug Description

write_note with overwrite behaves differently from what the tool documents, and several sub-cases silently lose frontmatter keys:

1. Documented-vs-actual on overwrite: the tool documents that overwriting replaces the note, but the server merge-preserves unrecognized frontmatter keys (a note carrying custom keys keeps them through an overwrite).
2. Content-carried frontmatter is discarded on overwrite rather than merged.
3. Malformed base discard: a base note with malformed frontmatter loses its keys silently during the overwrite path.
4. Tag regeneration drops keys: regenerated tags can clobber unrecognized keys in the same write.

Net effect: callers cannot reason about which frontmatter survives a write_note — the four paths above give four different answers.

Steps To Reproduce

1. Create a note with custom frontmatter keys (e.g. custom_key: value) plus standard title/type/tags
2. Call the write_note MCP tool against the same title/path with overwrite: true, new content, and no mention of custom_key
3. Repeat with: frontmatter embedded in the content block; a base note whose frontmatter is malformed; a write that regenerates tags
4. Inspect the note file after each

Expected Behavior

One documented, test-pinned contract: overwrite either replaces (all keys gone unless re-supplied) or merges (unrecognized keys preserved) — consistently — and the tool's description matches the implementation. Silent key loss should never happen.

Actual Behavior

• Path 1: custom_key survives (merge behavior) though the tool documents replacement
• Paths 2-4: keys are silently lost, no warning in the tool response

(Verified on a live 0.23.0 server; the four sub-cases are enumerated with the losing paths named in the original investigation.)

Environment

• OS: macOS 15 (arm64)
• Python version: 3.14 (uv-managed)
• Basic Memory version: 0.23.0
• Installation method: uv tool install basic-memory==0.23.0
• Claude Desktop version: n/a (MCP tool calls via a stdio server)