Virtualise horizontal rendering of extremely long unwrapped editor lines

[coderabbitai]

Summary

Profile and reduce the time and memory spent shaping and rendering extremely long source lines when soft_wrap: "none" is set. PR #152 makes complete unwrapped lines available but shapes the full line, including text outside the horizontal viewport. Keep that correctness fix while limiting work for off-screen text.

Affected areas

• crates/editor/src/element.rs: editor line measurement, layout, painting, replacement chunks, selections, and hit-testing.
• The editor display/wrapping pipeline where viewport-dependent layout requires it.

Proposed work

• Profile first open, editing, horizontal scrolling, and selection on very long unwrapped ASCII and multibyte lines. Establish a baseline for time and memory use.
• Design horizontal text virtualisation so rendering work scales with the visible range plus appropriate overscan rather than the entire line where feasible.
• Preserve full logical line width, horizontal scrolling, hit-testing, selection, replacement chunks, and correct behaviour when switching between soft_wrap: "none" and editor-width wrapping. Account for grapheme and shaping boundaries at viewport edges.
• Add focused correctness tests and a reproducible performance benchmark or profiling scenario.

Acceptance criteria

• Long unwrapped lines remain one display row per logical line and are not truncated.
• Horizontal scrolling, hit-testing, selections, and replacement chunks work beyond the previous 1,024-byte cutoff, including multibyte text and viewport boundaries.
• Editor-width wrapping still works when re-enabled.
• Measurements show reduced time and/or memory for representative extremely long unwrapped lines without a correctness regression.

References

• PR: #152
• Request: follow-up comment
• Original correctness issue: #146

Requested by @kjanat.