fix: wrap EditDelta.new_lines in Arc to reduce memory from deep cloning

[warp-dev-github-integration]

Summary

Wraps EditDelta.new_lines in Arc<Vec<StyledBufferBlock>> to eliminate expensive deep cloning when EditDelta is propagated through the event system.

Problem

Heap profiling from Sentry issue 7259255054 shows ~9.3 GB of cumulative allocations from Vec<StyledBufferBlock>::clone() in CodeEditorModel::handle_content_model_event. This is the #2 allocation site after the buffer's SumTree construction itself.

When a file is loaded or its content changes, the EditDelta (containing styled buffer blocks for the entire changed region) gets deep-cloned every time it passes through the event system:

1. From BufferEvent::ContentChanged to delay rendering queue (delta.clone())
2. From delay rendering to render state (delta.clone() — this one was completely unnecessary since the delta was already owned)
3. From BufferEvent::ContentChanged to render state (delta.clone())

For large files, each clone duplicates all the StyledBufferBlock strings, causing massive transient allocations.

Changes

• EditDelta.new_lines: Changed from Vec<StyledBufferBlock> to Arc<Vec<StyledBufferBlock>> so cloning is O(1) reference counting instead of O(n) deep copy
• layout_delta(): Uses Arc::try_unwrap() to cheaply unwrap when sole owner, falling back to clone only when shared
• DelayRendering::flush_render(): Removed unnecessary delta.clone() — the delta was already owned by value from consuming the vec
• Updated all EditDelta construction sites to wrap with Arc::new()

Testing

• cargo check -p warp_editor passes
• Existing tests are compatible since Arc<Vec<T>> auto-derefs to Vec<T> for reads

Changelog

CHANGELOG-IMPROVEMENT:
CHANGELOG-BUG-FIX:
CHANGELOG-IMAGE:
CHANGELOG-NEW-FEATURE:

---

Conversation: https://staging.warp.dev/conversation/57e99221-45e9-483b-bf35-ffee7c71c874
Run: https://oz.staging.warp.dev/runs/019e5841-4d9f-7185-969b-487b41700e56
This PR was generated with Oz.