🐛 FIX: dollarmath same-line close absorbs trailing list content

[KyleKing]

Fixes #147

A same-line close followed by trailing content that wasn't a label suffix (e.g. $$b$$ trailing) wasn't recognized as closed, so the rule fell through to its multi-line scan and silently swallowed every following line, including subsequent list items, up to the next $$ anywhere later in the document:

1. $$a$$
1. $$b$$ trailing
   1. $$c$$

This ambiguous case (closing marker present, but not at end of line and not a label) is now rejected outright, letting the line fall through to normal inline parsing instead.

[chrisjsewell]

Checked this out and reproduced #147 before/after. The fix resolves it: the issue's 1. $$a$$ / 1. $$b$$ trailing / $$c$$ input no longer swallows the following list item(s) into the first math token — the ambiguous same-line-close-with-trailing case now returns False and falls through to inline parsing. All 515 tests pass.

Coverage is solid:

• test_block_func_ambiguous_trailing_content parametrizes both allow_labels branches (the elif allow_labels: path and the else path both got the guard), which is exactly the split that matters.
• The dollar_math.md fixtures exercise it end-to-end under double_inline=True.
• CHANGELOG updated.

I confirmed labels still work ($$a=1$$ (lbl) → labeled block) and that $$a=1$$ (lbl) x — a label followed by trailing junk — is now correctly rejected rather than greedily scanning ahead.

One edge-case note inline about multi-line blocks whose opening line contains an internal $$, but it's consistent with the issue's intent. Looks good to me.

---

Generated by Claude Code