🐛 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

[chrisjsewell]

The guard is correct — by the time control reaches here we already know the line neither ends in $$ nor is a label close, so a second $$ in the remainder can only be a mid-line close with trailing junk, and rejecting it is right.

One edge worth being explicit about (not a blocker): this also changes handling of a genuine multi-line block whose opening line contains an internal $$, e.g.

$$a $$ b
c = 1
$$

Previously the same-line scan didn't fire and this parsed as one multi-line block with content a $$ b\nc = 1; now "$$" in lineText[2:] is true, so the block rule bails and the line falls through to inline parsing instead. That's consistent with the issue's "same-line close wins" intent and the input is pathological, so I think it's the right call — just flagging that the change isn't strictly limited to the same-line-close case.

Minor: "$$" in lineText[2:] is evaluated in both the allow_labels and the else branch; you could compute it once above the if, but it's trivial either way.

---

Generated by Claude Code