Lengthen the pre code fence so backtick runs can't close it early

[chuenchen309]

convert_pre emits a fixed three-backtick fence, so a <pre> whose content contains a ``` run (or longer) produces an ambiguous fenced code block:

from markdownify import markdownify as md
md("<pre>foo\n```\nbar</pre>")
# ```
# foo
# ```
# bar
# ```

That reparses (via any CommonMark parser) to three elements — a foo code block, a bar paragraph, and an empty code block — because the inner ``` closes the fence early. Per CommonMark §4.5, a closing fence must have at least as many backticks as the opening, so a 3-backtick fence can't wrap content that contains a 3-backtick line.

convert_code already handles this for inline code (it counts the longest backtick run and uses one more); convert_pre didn't.

Fix: compute the fence length from the longest backtick run in the content, at least three (keeping the previous default when there are no backticks), reusing the existing re_backtick_runs pattern.

max_backticks = max((len(match) for match in re.findall(re_backtick_runs, text)), default=0)
fence = '`' * max(3, max_backticks + 1)
return '\n\n%s%s\n%s\n%s\n\n' % (fence, code_language, text, fence)

Now <pre>foo\n```\nbar</pre> produces a 4-backtick fence and reparses back to a single equivalent code block.

Verification (re-runnable from the diff): added test_pre_backticks (content with , a bare , a````b, and plain text) — it fails on the current tree and passes with the fix; tests/ → 84 passed.

---

Disclosure: This PR was authored by an AI coding agent (Claude Code) running on this account: the AI found the bug, ran the repro, wrote the test, and wrote this description. The human account holder reviews every change and is accountable for it. The verification above is real and re-runnable from the diff. If this isn't the kind of contribution you want, say so and I'll close it.