Memory frontmatter normalization silently truncates unquoted values at ' #' (YAML comment dropped on re-serialize)

Environment: Claude Code 2.1.201, Windows 11, project auto-memory (~/.claude/projects/<slug>/memory/).

Bug

When the memory system rewrites a memory file's frontmatter (the normalization that folds unknown top-level keys into metadata: and injects node_type/originSessionId), unquoted scalar values are parsed per YAML — so a whitespace-preceded # starts a comment, and everything from the # on is permanently dropped on re-serialize. Issue/PR references (fixed in PR #456) are exactly what memory descriptions and provenance fields naturally contain, so this bites silently and repeatedly.

Repro

1. Write a memory file with description: proven pattern for #123 retirements.
2. Let any later session update that memory through the memory system.
3. The file now reads description: proven pattern for — no warning, and the text is unrecoverable.

Worst cases observed

• A description that _began_ with #977 … was emptied entirely (the key dropped from the file).
• Separately — observed once, same rewrite path — a file was left structurally broken: the closing --- delimiter removed, the injected metadata: block removed, and a double-quoted description's terminating quote dropped (unterminated scalar).

Expected

Frontmatter values should round-trip. Quoting values containing # on emit (any spec-compliant emitter does this) or preserving raw scalar text would both fix it; failing that, a write-time warning would at least make the loss visible.

Workaround we adopted

Hash-free wording (issue 123) or quoting the scalar, plus an index-time linter that warns on unquoted # in memory frontmatter.