getUserTemplateSelection double-decodes the dialog value

`getUserTemplateSelection` decodes the value it gets back from the dialog:

```ts
const templateValue = result.formData?.["templates-form"]?.template;
const decodedValue = templateValue ? decode(templateValue) : null;
```

This went in as a16f13b ("fix: regression in getUserTemplateSelection"), which only makes sense if encoded text was arriving at that point. That does not appear to be true now.

While fixing #173 we confirmed against a dev build that dialog values arrive already decoded. Dropdown (`enum`) variables are the clean test: `enum.ts` writes its options into the HTML as `` and nothing decodes them on the way back, yet dropdown values containing an apostrophe come through correctly. So the browser decodes the attribute and `formData` hands back the real value.

That makes this `decode()` a no-op in the ordinary case, and harmful in one edge case. `encode()` is applied to the option value on the way out, the browser decodes it once on parse, and `decode()` then runs a second time. A template whose title contains literal entity text is corrupted by that second pass:

- title `Q&A` → `encode` → `Q&A` → browser → `Q&A` → `decode` → `Q&A`

Either Joplin changed its form serialisation since March 2025, or the original regression had a different cause and this treated the symptom.

Worth confirming what the original regression actually was before removing it, rather than deleting it on the strength of the above. Low priority, since it needs an unusual note title to bite.

Start at getUserTemplateSelection and inspect enum.ts to trace how option values are encoded and returned through formData. Review commit a16f13b and issue #173 before deciding whether the original regression still applies. Done means the historical behavior is understood and the double-decoding edge case is addressed without corrupting literal entity text.

Written by the indexing model from the issue text.