Add defensive escaping for code blocks containing $ characters.
When protecting code (inline `...` or fenced ```...```), replace
$ with &esengine#36; (HTML entity). On restoration, unescape back to $.

This prevents KaTeX from attempting to parse math delimiters that
appear in code examples, regex patterns, or template literals.

Fixes: Pasted documentation about the math pipeline itself no longer
shows red KaTeX error text.

Tests: 3 new cases added, 106/106 passing

Previously, the Step 5 regex would greedily match '$5 and $' as a single
math expression with content '5 and ', then convert it to '&esengine#36;5 and &esengine#36;'
because the classifier correctly identified it as non-math. This was visually
correct but had two problems:

1. The greedy match would consume the closing dollar that belonged to the
   next currency token, causing cascade replacements.
2. Prose currency like 'These two apples cost $5 and $6' would have its
   dollar signs converted to HTML entities, which works but is unnecessary
   noise in the rendered output.

Changes:
- Step 5 regex now uses non-greedy matching (+\?) so '$5 and $' doesn't
  match '$5 and $' as a single pair
- When the classifier rejects a match, the original text is preserved
  unchanged (return _m) instead of being wrapped in HTML entities
- This keeps dollar signs visible in prose while still preventing them from
  being parsed as math

All 122 tests pass.

Add defensive escaping for code blocks containing $ characters.
When protecting code (inline `...` or fenced ```...```), replace
$ with &esengine#36; (HTML entity). On restoration, unescape back to $.

This prevents KaTeX from attempting to parse math delimiters that
appear in code examples, regex patterns, or template literals.

Fixes: Pasted documentation about the math pipeline itself no longer
shows red KaTeX error text.

Tests: 3 new cases added, 106/106 passing

Previously, the Step 5 regex would greedily match '$5 and $' as a single
math expression with content '5 and ', then convert it to '&esengine#36;5 and &esengine#36;'
because the classifier correctly identified it as non-math. This was visually
correct but had two problems:

1. The greedy match would consume the closing dollar that belonged to the
   next currency token, causing cascade replacements.
2. Prose currency like 'These two apples cost $5 and $6' would have its
   dollar signs converted to HTML entities, which works but is unnecessary
   noise in the rendered output.

Changes:
- Step 5 regex now uses non-greedy matching (+\?) so '$5 and $' doesn't
  match '$5 and $' as a single pair
- When the classifier rejects a match, the original text is preserved
  unchanged (return _m) instead of being wrapped in HTML entities
- This keeps dollar signs visible in prose while still preventing them from
  being parsed as math

All 122 tests pass.

Rebase onto current main-v2 plus five targeted cleanups called out in
the review:

1. Drop the &esengine#36; escape/unescape dance. Protected segments are stored
   out-of-band and swapped back wholesale, so the round-trip is a no-op
   — except for code that legitimately contains the literal text &esengine#36;
   (which got silently rewritten to $ on restore, corrupting the source).
   The header comment is also stale: the description claims restore does
   not unescape, but the code did.

2. Revert Step 5's greedy→non-greedy change. The char class
   [^$\n]+ already excludes $, so changing + to +? has no effect
   on match extent; the comment claiming it prevents cross-pair
   matching is wrong. Drop the change and the misleading comment.
   The "leave non-math pairs unchanged" behaviour is kept.

3. Restrict fenced-code detection to line-start. Allowing ``` anywhere
   in the line would swallow prose like "wrap code in ```blocks``` here"
   into a code region and break the math for the rest of the message —
   the CommonMark spec requires fences at line start. Single-line docs
   are still handled (the next matching fence is the closer).

4. Escape top-level % in math. KaTeX treats unescaped % as a LaTeX
   comment char and silently truncates the formula at end-of-line —
   "$x = 50%$" rendered as "x = 50" with no error. Add a top-level
   case in latexNormalizeForKatex that emits \% (already-escaped \%
   is handled above as a 2-char command, so no double-escape).

5. Trim oversized comments. Drop the // was: ... history notes in tests
   and the 8-12 line essays in mathNormalize / mathClassify that
   describe code that no longer exists or that the reader can see
   from the regex. The header still lists the pipeline as a map.

128 tests pass; typecheck clean.

Rebase onto current main-v2 plus five targeted cleanups called out in
the review:

1. Drop the &esengine#36; escape/unescape dance. Protected segments are stored
   out-of-band and swapped back wholesale, so the round-trip is a no-op
   — except for code that legitimately contains the literal text &esengine#36;
   (which got silently rewritten to $ on restore, corrupting the source).
   The header comment is also stale: the description claims restore does
   not unescape, but the code did.

2. Revert Step 5's greedy→non-greedy change. The char class
   [^$\n]+ already excludes $, so changing + to +? has no effect
   on match extent; the comment claiming it prevents cross-pair
   matching is wrong. Drop the change and the misleading comment.
   The "leave non-math pairs unchanged" behaviour is kept.

3. Restrict fenced-code detection to line-start. Allowing ``` anywhere
   in the line would swallow prose like "wrap code in ```blocks``` here"
   into a code region and break the math for the rest of the message —
   the CommonMark spec requires fences at line start. Single-line docs
   are still handled (the next matching fence is the closer).

4. Escape top-level % in math. KaTeX treats unescaped % as a LaTeX
   comment char and silently truncates the formula at end-of-line —
   "$x = 50%$" rendered as "x = 50" with no error. Add a top-level
   case in latexNormalizeForKatex that emits \% (already-escaped \%
   is handled above as a 2-char command, so no double-escape).

5. Trim oversized comments. Drop the // was: ... history notes in tests
   and the 8-12 line essays in mathNormalize / mathClassify that
   describe code that no longer exists or that the reader can see
   from the regex. The header still lists the pipeline as a map.

128 tests pass; typecheck clean.

Per maintainer review on PR esengine#3666: the literal $…$ pair is not
enough to keep a non-math token out of KaTeX, because remark-math
parses any $…$ it sees in the source and the classifier's reject
verdict only holds when the $ is hidden as a &esengine#36; entity.

Step 6: non-math pairs (currency $5, env vars $PATH) now wrap in
&esengine#36; entities, matching what step 5 already does for the
$<cmd>{…}$ pair. The decoded entity still renders as a literal
dollar.

Test updates:
- Two eq assertions flipped to expect the entity form.
- Drop the stale '$5$ is filtered to entities' comment.
- New render-boundary section runs the real react-markdown +
  remark-math + rehype-katex path; the previous golden cases never
  crossed the prose→parser boundary, so the regression was
  undetectable at the normalizeMath layer.

132 passed, 0 failed (was 129).

Add defensive escaping for code blocks containing $ characters.
When protecting code (inline `...` or fenced ```...```), replace
$ with &esengine#36; (HTML entity). On restoration, unescape back to $.

This prevents KaTeX from attempting to parse math delimiters that
appear in code examples, regex patterns, or template literals.

Fixes: Pasted documentation about the math pipeline itself no longer
shows red KaTeX error text.

Tests: 3 new cases added, 106/106 passing

Previously, the Step 5 regex would greedily match '$5 and $' as a single
math expression with content '5 and ', then convert it to '&esengine#36;5 and &esengine#36;'
because the classifier correctly identified it as non-math. This was visually
correct but had two problems:

1. The greedy match would consume the closing dollar that belonged to the
   next currency token, causing cascade replacements.
2. Prose currency like 'These two apples cost $5 and $6' would have its
   dollar signs converted to HTML entities, which works but is unnecessary
   noise in the rendered output.

Changes:
- Step 5 regex now uses non-greedy matching (+\?) so '$5 and $' doesn't
  match '$5 and $' as a single pair
- When the classifier rejects a match, the original text is preserved
  unchanged (return _m) instead of being wrapped in HTML entities
- This keeps dollar signs visible in prose while still preventing them from
  being parsed as math

All 122 tests pass.

Rebase onto current main-v2 plus five targeted cleanups called out in
the review:

1. Drop the &esengine#36; escape/unescape dance. Protected segments are stored
   out-of-band and swapped back wholesale, so the round-trip is a no-op
   — except for code that legitimately contains the literal text &esengine#36;
   (which got silently rewritten to $ on restore, corrupting the source).
   The header comment is also stale: the description claims restore does
   not unescape, but the code did.

2. Revert Step 5's greedy→non-greedy change. The char class
   [^$\n]+ already excludes $, so changing + to +? has no effect
   on match extent; the comment claiming it prevents cross-pair
   matching is wrong. Drop the change and the misleading comment.
   The "leave non-math pairs unchanged" behaviour is kept.

3. Restrict fenced-code detection to line-start. Allowing ``` anywhere
   in the line would swallow prose like "wrap code in ```blocks``` here"
   into a code region and break the math for the rest of the message —
   the CommonMark spec requires fences at line start. Single-line docs
   are still handled (the next matching fence is the closer).

4. Escape top-level % in math. KaTeX treats unescaped % as a LaTeX
   comment char and silently truncates the formula at end-of-line —
   "$x = 50%$" rendered as "x = 50" with no error. Add a top-level
   case in latexNormalizeForKatex that emits \% (already-escaped \%
   is handled above as a 2-char command, so no double-escape).

5. Trim oversized comments. Drop the // was: ... history notes in tests
   and the 8-12 line essays in mathNormalize / mathClassify that
   describe code that no longer exists or that the reader can see
   from the regex. The header still lists the pipeline as a map.

128 tests pass; typecheck clean.

Cherry-picks the maintainer's review patch from PR esengine#3666 onto
dev-new-features so the local Reasonix app renders currency and
env-var tokens as literal dollars instead of triggering katex
errors.

Per maintainer feedback: a literal $…$ pair in normalizeMath
output is not enough to keep a non-math token out of KaTeX, because
remark-math parses any $…$ it sees in the source. The classifier's
reject verdict only holds when the $ is hidden as a &esengine#36; entity.

Step 6: non-math pairs (currency $5, env vars $PATH) now wrap in
&esengine#36; entities. Decoded entity still renders as a literal dollar.

Test updates:
- Two eq assertions flipped to expect the entity form.
- Drop the stale '$5$ is filtered to entities' comment.
- New render-boundary section runs the real react-markdown +
  remark-math + rehype-katex path; the previous golden cases never
  crossed the prose→parser boundary, so the regression was
  undetectable at the normalizeMath layer.

132 passed, 0 failed (was 129).

Add defensive escaping for code blocks containing $ characters.
When protecting code (inline `...` or fenced ```...```), replace
$ with &esengine#36; (HTML entity). On restoration, unescape back to $.

This prevents KaTeX from attempting to parse math delimiters that
appear in code examples, regex patterns, or template literals.

Fixes: Pasted documentation about the math pipeline itself no longer
shows red KaTeX error text.

Tests: 3 new cases added, 106/106 passing

Previously, the Step 5 regex would greedily match '$5 and $' as a single
math expression with content '5 and ', then convert it to '&esengine#36;5 and &esengine#36;'
because the classifier correctly identified it as non-math. This was visually
correct but had two problems:

1. The greedy match would consume the closing dollar that belonged to the
   next currency token, causing cascade replacements.
2. Prose currency like 'These two apples cost $5 and $6' would have its
   dollar signs converted to HTML entities, which works but is unnecessary
   noise in the rendered output.

Changes:
- Step 5 regex now uses non-greedy matching (+\?) so '$5 and $' doesn't
  match '$5 and $' as a single pair
- When the classifier rejects a match, the original text is preserved
  unchanged (return _m) instead of being wrapped in HTML entities
- This keeps dollar signs visible in prose while still preventing them from
  being parsed as math

All 122 tests pass.

Rebase onto current main-v2 plus five targeted cleanups called out in
the review:

1. Drop the &esengine#36; escape/unescape dance. Protected segments are stored
   out-of-band and swapped back wholesale, so the round-trip is a no-op
   — except for code that legitimately contains the literal text &esengine#36;
   (which got silently rewritten to $ on restore, corrupting the source).
   The header comment is also stale: the description claims restore does
   not unescape, but the code did.

2. Revert Step 5's greedy→non-greedy change. The char class
   [^$\n]+ already excludes $, so changing + to +? has no effect
   on match extent; the comment claiming it prevents cross-pair
   matching is wrong. Drop the change and the misleading comment.
   The "leave non-math pairs unchanged" behaviour is kept.

3. Restrict fenced-code detection to line-start. Allowing ``` anywhere
   in the line would swallow prose like "wrap code in ```blocks``` here"
   into a code region and break the math for the rest of the message —
   the CommonMark spec requires fences at line start. Single-line docs
   are still handled (the next matching fence is the closer).

4. Escape top-level % in math. KaTeX treats unescaped % as a LaTeX
   comment char and silently truncates the formula at end-of-line —
   "$x = 50%$" rendered as "x = 50" with no error. Add a top-level
   case in latexNormalizeForKatex that emits \% (already-escaped \%
   is handled above as a 2-char command, so no double-escape).

5. Trim oversized comments. Drop the // was: ... history notes in tests
   and the 8-12 line essays in mathNormalize / mathClassify that
   describe code that no longer exists or that the reader can see
   from the regex. The header still lists the pipeline as a map.

128 tests pass; typecheck clean.

Per maintainer review on PR esengine#3666: the literal $…$ pair is not
enough to keep a non-math token out of KaTeX, because remark-math
parses any $…$ it sees in the source and the classifier's reject
verdict only holds when the $ is hidden as a &esengine#36; entity.

Step 6: non-math pairs (currency $5, env vars $PATH) now wrap in
&esengine#36; entities, matching what step 5 already does for the
$<cmd>{…}$ pair. The decoded entity still renders as a literal
dollar.

Test updates:
- Two eq assertions flipped to expect the entity form.
- Drop the stale '$5$ is filtered to entities' comment.
- New render-boundary section runs the real react-markdown +
  remark-math + rehype-katex path; the previous golden cases never
  crossed the prose→parser boundary, so the regression was
  undetectable at the normalizeMath layer.

132 passed, 0 failed (was 129).

The inline-math classifier accepted comma-separated tuples like (A, B)
or (1, 2, 3), but not permutation cycle notation — (12), (123),
(12)(34) — where digits are packed together without commas. These fell
through every accept rule and returned false, so normalizeMath wrapped
them in &esengine#36; entities and they rendered as literal dollar signs
instead of going through remark-math/rehype-katex.

Add a rule that accepts one or more parenthesised digit groups:
  if (/^(?:\(\d+\))+$/.test(math)) return true;

This is specific enough to avoid false positives: a parenthesised
all-digit group is currency-shaped in prose only when it looks like
(5), which is rare and never written inside $...$. Comma tuples
continue through the existing rule.

+4 regression cases (transposition, 3-cycle, product-of-transpositions,
and an end-to-end normalizeMath check). 207/207 pass.