docs: clarify wrapForFrac and streaming math-fence rationale

Address two Copilot review comments on PR #17175.

- `wrapForFrac` doc said "additive operators or whitespace" but the
  implementation also matches `*` and `/`. The wider behaviour is the
  one we want (nested products and fractions need parens to disambiguate
  inline `/`), so the doc is updated to match instead of tightening the
  regex.

- `fenceOpenAt` was flagged as "overly conservative" vs. `markdown.tsx`,
  which falls back to paragraph rendering for unclosed `$$` openers.
  Mirroring that fallback in the streaming chunker would prematurely
  commit a paragraph rendering of the unclosed opener to the monotonic
  stable prefix, where it would be frozen and become wrong the moment
  the closer streams in. The asymmetry is deliberate; document why so
  it isn't "fixed" again later.

Made-with: Cursor

ui-tui/src/lib/mathUnicode.ts

@@ -644,10 +644,13 @@ const replaceFracs = (input: string): string => {
 }
 
 // Wrap multi-token expressions in parens so `\frac{a+b}{c}` becomes
-// `(a+b)/c` rather than `a+b/c`. We only wrap when the expression has
-// loose precedence — additive operators or whitespace that would change
-// meaning under inline `/`. Atomic factors like `n!`, `x^2`, `\sin x`
-// don't need parens; wrapping them just clutters the output.
+// `(a+b)/c` rather than `a+b/c`. We wrap whenever inline `/` would
+// change the meaning — that's any binary operator (`+`, `-`, `*`, `/`)
+// or whitespace separating tokens. `*` and `/` matter because nested
+// fractions and products like `\frac{a*b}{c}` and `\frac{1/x}{y}` would
+// otherwise read as `a*b/c` (right-associative ambiguity) and `1/x/y`.
+// Atomic factors like `n!`, `x^2`, `\sin x` don't trigger any of these
+// and stay un-parenthesised — wrapping them just clutters the output.
 const wrapForFrac = (expr: string) => {
   const trimmed = expr.trim()