Perf: replace-all, yank and repeat counts as single edits

Each piece-table edit costs time linear in the buffer (piece lookup,
line-index update), so operations issuing one edit per match, line or
repetition were quadratic:

- Plain and regex replace-all build the new text in one pass and apply
  it as one delete + one insert (one undo group, one chunked journal
  record). 12 MB with 229k matches: minutes -> 0.14 s.
- Yank inserts the whole kill in one edit (it split and re-trimmed line
  by line): 200k lines in 0.02 s.
- InsertText with a repeat count inserts the repeated text once; the
  total is capped at 256 MiB (also across visual-line broadcast).
- Incremental regex search skips lines over 20,000 bytes and renderer
  match highlighting over 10,000 (the previous change raised the render
  limit to 1 MB): std::regex can be quadratic in line length even for
  ordinary patterns such as '.*q', uninterruptibly, and these run on
  every keystroke or frame. Explicit regex replace still processes all.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015rcVQiiWyTzoNrsvLSaAfB

RegexGuard.h

@@ -12,9 +12,12 @@
 #include <string>
 
 namespace kte {
-// Renderers highlight regex matches only on lines up to this many bytes (to
-// bound per-frame work); longer lines are drawn without match highlighting.
-constexpr std::size_t kRegexRenderLineLimit = 1000000;
+// Renderers highlight regex matches only on lines up to this many bytes, and
+// incremental regex search skips longer lines: std::regex can take time
+// quadratic in line length even for ordinary patterns, with no way to
+// interrupt it, and these run on every frame or keystroke.
+constexpr std::size_t kRegexRenderLineLimit      = 10000;
+constexpr std::size_t kRegexIncrementalLineLimit = 20000;
 
 // Run fn to completion on a thread with a large stack (address space is
 // reserved, pages are committed only as used), so regex work over long lines