Apostrophes and quotes in variables are converted to HTML entities in the generated note

Characters like `'`, `"`, `&` and `<` typed into a template variable come out as HTML entities in the generated note instead of as plain text.

### Steps to reproduce

Create a template:

```
---
note_text: text
---

{{ note_text }}
```

Create a note from it and enter `it's a "test"` when prompted.

**Expected:** `it's a "test"`
**Actual:** `it's a "test"`

The note renders correctly in the viewer, since Joplin's markdown renderer passes the entities through, but the underlying markdown is wrong. It shows up as soon as you edit the note, search it, sync it elsewhere, or export it.

### Cause

`Handlebars.compile()` is called with default options in `src/parser.ts`, so every `{{ variable }}` is run through `escapeExpression`, which encodes `& < > " ' \` =`. That is correct for an HTML target, but templates render into markdown notes.

Two call sites are affected:

- the note body, in `parseTemplate`
- `parseSpecialVariables`, so `template_title` and `template_tags` are mangled the same way and the problem reaches the note title, not just its body

### Workaround

Use the triple stache, `{{{ note_text }}}`, which bypasses escaping. It works today but is not discoverable, and it should not be necessary for ordinary text.

### Fix

Pass `{ noEscape: true }` to both compile calls. `{{{ variable }}}` behaves identically under `noEscape`, so existing templates are unaffected.

### Update: confirmed fixed

Verified against a dev build in the app, not just in jest.

Dropdown (`enum`) variables were checked at the same time and are unaffected. That also answers an open question about this bug: values arrive from the dialog already decoded, so `noEscape` is the complete fix and no decoding is needed on the way in.

Start in src/parser.ts at parseTemplate and parseSpecialVariables, then reproduce the issue with the template and input shown. Done means apostrophes and quotes remain literal in the generated note, including the title and tags, while existing triple-stache behavior remains unchanged.

Written by the indexing model from the issue text.