Fix iPhone history lag: cap web client history buffers and coalesce renders

[serrebidev]

Problem

On iPhone, tapping a menu choice grows to 10–20s of lag after a session has run for a while. Desktop is unaffected.

Root cause is the web client's history system:

• store.addHistory() pushes to history buffers with no cap, and every non-all line is also mirrored into the all buffer (the default visible one) — so buffers grow with the entire session.
• history.js render() runs on every notify() and rebuilds the whole <textarea> via lines.join("\n") plus a forced reflow (scrollTop = scrollHeight). A single tap emits a burst of speak/chat lines, each firing its own notify(), so cost per tap ≈ (lines added) × (total history) — quadratic and growing all session.
• Mobile is hit hardest: renderMobileVisibility() shows the growing #history-log <p> list that desktop hides, so phones pay for both the textarea rebuild and an unbounded visible DOM, on slower hardware.

Fix

• store.js — cap each history buffer at 500 lines (FIFO trim from the front). Bounds memory and makes every render O(cap) instead of O(session). History navigation indexes from the end, so front-trimming never disturbs scrollback position.
• ui/history.js — coalesce renders into one requestAnimationFrame (a K-line burst → 1 render, not K), skip the DOM work entirely when the visible buffer is unchanged (keeps menu navigation cheap), and rebuild the capped log from scratch (the old count-based incremental append silently broke once the buffer trimmed from the front).

Testing

• Focused unit check of the cap (600 pushes → length 500, oldest dropped, all mirror capped, direct-all path not double-pushed): pass.
• Existing web tests (tests/markdown_viewer_security.test.mjs): 2/2 pass.

Notes

• Intentionally did not bump version.js in this PR to avoid merge conflicts in the integration branch; asset freshness is already handled by the server's Cache-Control: no-cache, must-revalidate + ETag.

🤖 Generated with Claude Code