fix: don't de-indent HTML inside fenced code blocks

[reidransom]

Hello- love this repo, I'm using it on all my websites. This is my first PR. Let me know if I can make any changes or missed any guidelines. Thank you!

deIndentHTMLBlocks operates on raw markdown lines before Goldmark parses them, so a line like

inside a ``` fence started an "HTML block" and the following indented code-sample lines lost their leading spaces in the rendered

 output.

Track fence state (``` and ~~~) and leave fenced content untouched.

[osteele]

Thanks for the clear fix and tests. I found one blocking fence-matching edge case: inCodeFence = !inCodeFence treats every matching fence line as the closing delimiter. A four-backtick fence may legitimately contain a triple-backtick line, and a backtick fence may contain ~~~; both currently end fence tracking early and allow HTML indentation to be stripped.

For example, the outer fence here uses four backticks, so the triple-backtick lines are content:

````html
```
<ul>
    <li>item</li>
</ul>
```
````

The current implementation toggles fence tracking off at the first triple-backtick line and changes <li>item</li> to <li>item</li>.

Please track the opening delimiter character and length, and only close on the same character with at least that length. Regression tests for longer outer fences and mixed delimiters would cover this.

[osteele]

Thanks for the clear fix and tests. Re-filing my earlier comment as a formal review so the status is visible from your side — the substance is unchanged.

inCodeFence = !inCodeFence treats every matching fence line as the closing delimiter. A four-backtick fence may legitimately contain a triple-backtick line, and a backtick fence may contain ~~~; both currently end fence tracking early and allow HTML indentation to be stripped.

Please track the opening delimiter's character and length, and only close on the same character with at least that length.

I ran the two cases against this branch's deIndentHTMLBlocks to confirm they reproduce:

FAIL  four-backtick outer fence containing ``` lines
FAIL  backtick fence containing ~~~ line
PASS  plain triple-backtick fence (this PR's own test)

In both failing cases <li>item</li> loses its indentation. Here are the two cases in the style of the existing table, ready to drop into TestDeIndentHTMLBlocks:

{
    name:  "longer outer fence containing shorter fence lines",
    input: "````html\n```\n<ul>\n    <li>item</li>\n</ul>\n```\n````\n",
    check: func(t *testing.T, result string) {
        require.Contains(t, result, "    <li>item</li>")
    },
},
{
    name:  "backtick fence containing tilde fence lines",
    input: "```\n~~~\n<ul>\n    <li>item</li>\n</ul>\n~~~\n```\n",
    check: func(t *testing.T, result string) {
        require.Contains(t, result, "    <li>item</li>")
    },
},

One other thing to pick up when you push: the branch now conflicts with main, but only in CHANGELOG.md, where both sides added entries under ## [Unreleased]. The code changes still merge cleanly, so it should be a quick rebase.

The rest of the change is good — the approach is right and the existing tests cover the common case well. Thanks for the contribution, and sorry for the slow signal on this one; my earlier note was a plain comment, so GitHub never showed you that it was blocking.

[reidransom]

Thank you for the detailed feedback and test cases. Made the following updates,

1. Track opening fence marker and length
2. Close only on the same marker
3. Require closing-fence trailing content to be whitespace only. Per CommonMark (https://spec.commonmark.org/0.31.2/#fenced-code-blocks), closing fences may be followed only by spaces or tabs.

Thank you!