fix: reject inline math when $ is followed by digit (currency false positive)

[toanalien]

Summary

• Fix renderMd() inline math regex falsely matching currency amounts as KaTeX math expressions
• Text like $1,000 xuống ~$95 was rendered as garbled math instead of literal text
• Add structural test to guard against regression

Problem

The $...$ inline math regex in renderMd() (static/ui.js:3103) matched $1,000 xuống ~$ as an inline math expression because:

1. Opening $ followed by 1 satisfied [^\s$\n] (non-space, non-dollar, non-newline)
2. ,000 xuống matched the middle [^$\n]*?
3. ~ before closing $ satisfied [^\s$\n]

This caused the $ signs to be consumed, the content between them to render as KaTeX math (italic text with ~ as subscript operator), and 95 to appear detached after the closing delimiter.

The streaming-markdown (smd) library already handles this correctly via its se() function which rejects $ followed by digits. But renderMd() (used for finalized/history messages) lacked this guard.

Fix

Regex change in static/ui.js:

Part	Before	After
First char after $	[^\s$\n]	[^\s$\d\n]
Single-char alternate	\S	[^\s\d]

Adding \d to the exclusion class rejects math when the first character after $ is a digit (0-9), which is a strong currency signal ($1,000, $50, $99.99).

Legitimate math expressions like $x^2$, $\alpha + \beta$ are unaffected since they start with letters or backslash.

Test plan

• New structural test: test_inline_math_regex_rejects_digit_after_opening_dollar
• All 35 tests in test_issue347.py pass
• All 106 tests in test_renderer_comprehensive.py + test_renderer_js_behaviour.py pass (no regression)
• Manual test: load a chat session containing $1,000 xuống ~$95 and verify literal rendering

[nesquena-hermes]

Reading the diff at static/ui.js:3098-3106 against origin/master, plus the surrounding renderMd() math-stash block (master static/ui.js:3096-3106), the change is correctly scoped and the root-cause analysis in the description holds up.

What the diff does

// before
s=s.replace(/\$([^\s$\n][^$\n]*?[^\s$\n]|\S)\$/g, ...)
// after
s=s.replace(/\$([^\s$\d\n][^$\n]*?[^\s$\n]|[^\s\d])\$/g, ...)

Adding \d to the opening-boundary class ([^\s$\d\n]) and to the single-char alternate ([^\s\d]) means a $ immediately followed by a digit is no longer eligible to open inline math. For $1,000 xuống ~$95 the opening $1 now fails the first-char class, so the delimiter pair never forms and the text renders literally.

Verification

I checked the two relevant invariants in isolation. The new pattern still matches genuine math and now rejects the currency forms:

"$x$"               -> [MATH:$x$]
"$x^2$"             -> [MATH:$x^2$]
"$\alpha$"          -> [MATH:$\alpha$]
"$5$"               -> $5$         (left literal)
"$1,000 xuống ~$95" -> $1,000 xuống ~$95   (left literal)

So legitimate expressions (letter or backslash after $) are unaffected, which matches the claim in the PR body.

One thing worth calling out

The change also means a bare $5$ no longer renders as math. That is intentional and aligns renderMd() with the streaming-markdown path (se() guard) the description references, so the finalized-history renderer and the live-stream renderer now agree. That is the right call — currency is overwhelmingly more common than single-digit inline math in chat — but it is a real (small) behavior change worth a line in the PR description so a future reader doesn't read it as an accidental regression.

Test

The guard test in tests/test_issue347.py is structural (asserts \d appears in the inline-regex source line) rather than behavioral. That's consistent with the existing test_inline_math_regex_requires_non_space_boundaries style in that file, so it fits. If you wanted stronger coverage, a behavioral case feeding $1,000 ~$95 through the renderer and asserting the literal $ survives would catch a future regex refactor that happens to keep \d in the source but breaks the match — but the structural test is in keeping with the file's conventions and is fine as-is.

Net: minimal, correctly targeted, aligned with the smd renderer. Looks good.

[nesquena-hermes]

Shipped in v0.51.199 (stage-batch11, via #3353). Thanks @toanalien — currency like $1,000 no longer renders as inline math. Note for users who relied on digit-leading inline math: use \(2x = 4\) or $$2x = 4$$ (the $2x$ form is now intentionally rejected, matching smd's se() guard). Opus confirmed the display-math / \(...\) / table-escape paths are all unaffected. 🎉