CRLF line endings breaks Obsidian tasks integration

Subject: Obsidian integration ignores morgen-tasks-include and adds a new task ID on every sync for notes with Windows (CRLF) line endings

Environment: Morgen desktop 4.0.6 on Windows 11. Obsidian integration with task ID policy set to add IDs, note inclusion default set to include. Morgen Tasks Obsidian plugin 1.0.7.

Summary: For any Markdown note saved with CRLF line endings, the Obsidian integration (1) ignores the morgen-tasks-include frontmatter property, and (2) appends a new 🆔 task ID to every open checkbox on every sync, forever. Notes with LF line endings work correctly. CRLF is the default for many Windows tools, so this happens without the user doing anything unusual.

Steps to reproduce:

Create a note with CRLF line endings containing:

morgen-tasks-include: false

[ ] Test task

Let Morgen sync the vault a few times.

Expected: The note is excluded (morgen-tasks-include is false), so Morgen never writes to it. Even for an included note, a task should get exactly one ID.

Actual: The note is imported anyway, and every sync appends another ID to the same task line: "- [ ] Test task 🆔 aB3xY9 🆔 Qm7pLk 🆔 ...". In one real note we reached 740 IDs across 12 checkboxes, 60+ on a single line, within a few days.

Cause (from reading the shipped app bundle): notes are split on "\n" only, so on a CRLF file every line keeps a trailing "\r".

Frontmatter: getFrontmatter() splits on "\n" and requires the first line to equal "---". On a CRLF file that line is "---\r", so it returns null and the note falls back to the inclusion default. The property is never read.
ID loop: extractTasks_() splits on "\n" and passes each line, still ending in "\r", to the task parser. The parser's body match stops at the "\r", so it never sees an existing ID. The code then appends " 🆔 <newId>" to the raw line, which puts the ID after the "\r", and writes the file back with join("\n"). On the next sync the ID is again after the "\r", invisible, so another one is added. The file also ends up with stray bare "\r" characters in the middle of lines.

Suggested fix: split lines on /\r?\n/ (or strip a trailing "\r" before parsing), and write each line back with the file's original line ending, so a CRLF note stays CRLF. Apply the same handling in getFrontmatter(). Separately, a small heads-up: the inclusion check only honours the property when its value is a string ("true"/"false"). That works with the current line-based frontmatter reader, but if it is ever swapped for a real YAML parser, morgen-tasks-include: false would arrive as a boolean and be silently ignored.

Workaround: converting affected notes to LF line endings fixes both problems. The exemption is honoured and a single ID is written once. The accumulated duplicate IDs have to be removed by hand.