Short-circuit Delta.diff/2 for large payloads

[simonyang08]

Problem

Livebook.Text.Delta.diff/2 becomes prohibitively slow when a smart cell embeds a very large source payload (e.g. Excalidraw JSON): the Myers implementation's cost grows with the edit distance, and on large inputs even a small change can take many seconds (measured 43s on a ~75KB JSON-like payload with scattered edits on the unpatched baseline). Livebook appears to hang when the cell source is re-synced (#2916).

Change

Keep the existing fine-grained Myers path for normal inputs and short-circuit to a single replace when either input exceeds 100_000 UTF-16 code units (measured with Text.JS.length, matching the delta length convention used across this module):

• The replace is built through the public Delta.delete/2 + Delta.insert/2 constructors so append/2 normalization keeps the ops canonical: no zero-length deletes/inserts, and the adjacent pair is stored in the module's standard insert-then-delete form, like every other delta producer.
• Equal payloads short-circuit to an empty delta (the Myers path previously also produced an empty delta in that case).
• The threshold is exposed via Delta.large_payload_threshold/0 for tests and future tuning.

Fixes #2916.

Tests

• New regression test: above-threshold inputs complete quickly and yield a single replace; equal / large-deletion / large-insertion edges keep the canonical ops shape. The shape assertions fail on the unpatched baseline.
• mix test test/livebook/text/ test/livebook/session/data_sync_test.exs → 2 doctests, 97 tests, 0 failures.
• mix format --check-formatted passes.

Trade-off

For very large payloads a single edit may now send the full payload over the wire instead of a fine-grained diff — the trade-off suggested in the issue thread. Fine-grained concurrent editing of such payloads degrades to last-writer-wins on the replaced range, which seems acceptable when editor stability beats wire-size efficiency.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[jonatanklosko]

Hey @simonyang08, thank you for the PR! Short-circuting is the way to go, but if we only check the text against the limit, then a cell with a single long line will degrade to replace every time, even for changes where the long line is not affected. I opened #3215 with an expanded approach :)