fix: respect disabled frontmatter on rename and note creation

[mgajewskik]

Summary

• fix note rename so it no longer inserts frontmatter when frontmatter.enabled = false
• fix templated note creation so new notes also respect frontmatter.enabled = false
• add regression tests and a changelog entry for both flows

What changed

This PR fixes two paths that could still introduce YAML frontmatter even when frontmatter management was explicitly disabled.

1. The rename handler updated the note buffer through save_to_buffer(), which bypassed the frontmatter guard.
2. Template-based note creation copied template frontmatter verbatim, including the built-in default note template.

The fix makes both flows respect the same frontmatter decision logic used elsewhere in the plugin.

Implementation details

• update lua/obsidian/lsp/handlers/_rename.lua to use note:update_frontmatter(note.bufnr) instead of unconditionally saving frontmatter to the buffer
• update lua/obsidian/templates.lua to strip leading YAML frontmatter from cloned templates when the destination note should not save frontmatter
• preserve the rest of the template body content unchanged

Tests

Added regression coverage for:

• renaming the current plain note with frontmatter disabled
• renaming a referenced plain note from another buffer with frontmatter disabled
• creating a new note from the default note template with frontmatter disabled
• cloning a template with frontmatter disabled while preserving the template body

Verification

• stylua --check .
• selene --config selene/config.toml lua/ tests/
• typos lua
• make test
• lua-language-server --configpath .luarc.json --check on the changed files

[neo451]

sorry for the late response

respecting frontmatter.enabled is definitely important, especially in the rename

I see two potential issues in the implementation:

1. rename could leave stale frontmatter with existing frontmatter and old id, if we just skip updating frontmatter, but some references still have fronatmatter and ids, but this really a minor issue, it is more of the users responsibility to stick to one workflow
2. the note creation one I am not so sure we need, if you use a template with frontmatter, shouldn't you just insert it? what is the point of configuring no fronmatter and then have some templates with frontmatter? and using the leading --- to determining frontmatter is a bit shaky, just --- can just be a normal horizontal rule at the beginning, but this is also a nitpick though.

I'd say we just focus on making the rename right in this PR, you can look into the stale frontmatter issue, if it is not worth it we can just merge it as it is.