Slate history typing bursts need legacy-style merge heuristics before anything else

Problem

The missing strict RC history lane exposed a real issue.

Current slate-history was recording contiguous typing bursts as separate undo units unless the caller explicitly forced merging.

That made burst undo/redo pay repeated full restore cost and turned the first benchmark read into nonsense.

20 typed characters on a 5000-block document were taking about ~490ms to undo and redo in the compare lane
legacy Slate was vastly faster on the same benchmark family
the cost came from history batching policy before any deeper undo/redo implementation discussion even mattered

treating every committed text insert as its own history unit by default
jumping straight to deeper replay optimization before restoring the obvious merge behavior for contiguous text edits
using the strict history lane without first checking whether burst typing was even grouped sensibly

Restore legacy-style merge heuristics in with-history.ts:

After that fix, the same strict lane dropped from roughly ~490ms to the low 20ms range.

Typing bursts are one user intention, not twenty unrelated history moments.

If the history layer refuses to merge them, every later undo/redo benchmark is measuring batching policy failure before it measures replay cost.

Once the burst becomes one history batch again:

undo/redo cost falls back into the actual restore path cost
strict RC history coverage becomes interpretable
deeper optimization can be judged honestly instead of through a broken batch policy

before benchmarking history replay, verify the batch policy matches the user intention being benchmarked
if contiguous typing does not merge, fix that first
do not let strict benchmark lanes harden a fake problem created by bad batch boundaries