editor: Fix inlay map panic when stale inlays resolve out of order

[mikayla-maki]

While investigating ZED-7G6 ("buffer snapshot not found for excerpt boundary", 171 events), we added randomized coverage for a part of the display map space nothing previously tested: multibuffers whose excerpts are removed, re-added, and re-keyed while diffs (including all hunks expanded, as diff views configure), folded buffers, text folds, and inlays are present. Coverage spans hand-built layer stacks, real DisplayMap entities driven through split and unsplit transitions, and a collab following test in which the follower applies the leader's excerpt churn by deserializing view updates.

The investigation converged on a systemic root cause: multibuffer anchors do not preserve their comparison and resolution order across structural changes (a path key reused for a different buffer, a buffer leaving, a diff base text replaced), and many downstream consumers assume they do, either by feeding anchors to sorted-input-only APIs or by keeping persistent trees sorted by anchor comparison. Each such consumer is a separate crash family in Sentry, all panicking in the rope or sum-tree layers with "cannot summarize backward" or "cannot seek backward".

Three consumers are fixed here, each with a deterministic regression test that fails before its fix:

1. InlayMap::sync: inlays anchored in a buffer whose path key was reused resolve to the end of the reused path's region while sorting before anchors into the new buffer, corrupting the binary search over inlays. Fixed by skipping inlays that resolve before content already rebuilt.
2. Excerpt::new via reversed ranges (ZED-79W, 19 events / 17 users): a reversed range from a language server, reachable through find-all-references, produced an excerpt whose anchors resolve backward. Fixed by ordering the endpoints in build_excerpt_ranges.
3. Vim mark serialization (ZED-APE, ZED-AR0, ZED-APW, ~34 events): a mark's anchors are in caller order (paired marks like [ and ] correspond by index, so storage cannot sort), but serialization summarized them with a sorted-input-only API. Fixed by summarizing each anchor independently.

ZED-7G6 itself is now reproduced end to end, with an artifact at every link of the chain:

4. Fold tree ordering — reproduced deterministically in test_folds_stay_sorted_when_diff_base_text_replaced. With all diff hunks expanded, folds inside a deleted hunk share a text anchor and are ordered only by their diff_base_anchors into the diff's base text. When the base text changes and deletes the region under one anchor, that anchor becomes invalid, and comparing a valid base anchor against an invalid one falls back to the text anchor's bias (ExcerptAnchor::cmp, the (Some, None)/(None, Some) arms). The comparator's answer is consistent with where the anchors resolve now, but opposite to the answer it gave when the folds were inserted — the comparator is time-variant, so the persistent fold tree becomes unsorted without being touched.
5. Propagation to a stale header block — reproduced deterministically in test_removing_buffer_removes_header_after_diff_base_changes, which replays a sequence found by the new targeted fuzz test test_stale_buffer_header_after_diff_base_change (seed 1316): because the fixture guarantees fold disorder from the first operation, seed hunting only has to search the short distance from disorder to staleness. After a handful of edits, base changes, and buffer churn, the block map's row accounting is displaced; removing a buffer then emits edits that miss its header row, and the block map keeps a header block referencing a buffer absent from the snapshot — resolving that header during render is ZED-7G6's exact panic. Build profiles determine which symptom surfaces, matching the field distribution: debug builds die earlier and louder (BlockMap::sync's row-accounting debug_assert, or subtract-with-overflow in the tab/wrap maps), while release builds — no debug assertions, and no overflow checks in [profile.release], so those subtractions silently wrap — continue to the stale header. This mirrors how "cannot seek backward" families outnumber ZED-7G6's 171 events in Sentry.
6. FoldMap::sync "cannot seek backward" (reachable from the same fixture, dozens of seeds): the unsorted fold tree propagates until a sync cursor seeks backward. The same panic message accounts for ~30 open Sentry issues, including ZED-95K (200 events / 151 users), whose stack blames highlight anchors on the same render path — another consumer of the same disease.

Two tests fail on purpose and keep CI red until the root cause is fixed: test_folds_stay_sorted_when_diff_base_text_replaced (the comparator instability) and test_removing_buffer_removes_header_after_diff_base_changes (the stale header). Drop the corresponding commits if a green branch is needed in the meantime.

Supporting infrastructure added along the way: the fold map's fold-order invariant dumps both offending folds' anchor internals and resolved offsets on failure (how the time-variant comparator branch was identified); two MultiBufferSnapshot invariants run inside every existing test; the "buffer snapshot not found" panic is self-describing, enumerating the snapshot's buffers, excerpts, path indexes, and anchor buffer ids; and the display map's test-only invariants can be skipped per-thread (production_simulation::SimulateProductionGuard) or process-wide (SIMULATE_PRODUCTION=1) so corruption propagates the way it does in production builds, where no invariants run.

Testing:

• Regression tests test_sync_after_path_key_reused_for_different_buffer, test_set_excerpts_with_reversed_and_out_of_bounds_ranges, and test_mark_serialization_with_unsorted_anchors fail before their fixes and pass after.
• test_folds_stay_sorted_when_diff_base_text_replaced and test_removing_buffer_removes_header_after_diff_base_changes deterministically reproduce the unfixed root cause and its ZED-7G6 endpoint (red by design, see above).
• ITERATIONS=1000+ runs of the three display-layer fuzzers pass at OPERATIONS=40..80.
• The new collab following test passes across 300 scheduler interleavings.
• Full editor (897 of 899; the 2 failures are the deliberate red tests), multi_buffer (59), vim (564), and collab (186) suites pass.

---

Root cause analysis conclusion. The causal chain for ZED-7G6 is complete, with a deterministic test at each end and every intermediate link observable. The root cause is that multibuffer anchor comparison and resolution are not stable across structural changes (a path key reused for a different buffer, a buffer leaving, a diff base text replaced), while consumers throughout the display map assume they are. From that root: a diff base change unsorts the fold map's anchor-keyed fold tree; the disorder propagates through syncs that emit edits misdescribing the actual change (caught by the new assert_wrap_edits_cover_changes coverage checker); the block map recomputes only rows the edits cover, by design, so a removed buffer's header block survives, referencing a departed buffer — ZED-7G6's exact panic. Most corrupted runs die earlier and louder in the "cannot seek backward" / "cannot summarize backward" families, matching their higher Sentry event counts relative to ZED-7G6.

The curative fix is at the root, not the crash sites: either re-key anchor-sorted structures when their comparator's inputs change (e.g. re-anchor folds when a diff base is replaced), or give anchors an invalidation contract (a structure version that forces re-resolution). That is a design decision for the owners of multi_buffer; this PR deliberately stops at diagnosis, reproduction, and the three caller-level fixes above.

Release Notes:

• Fixed a crash that could occur when inlay hints were present while a multibuffer replaced the contents of a file, such as a diff view whose base changed.
• Fixed a crash that could occur when opening search results or references in a multibuffer when a language server returned a reversed range.
• Fixed a crash that could occur when setting vim marks with multiple cursors.