Search & Replace: match stepping (Ctrl+Alt+→/←) and Enter-open land on stale pre-edit positions after the buffer is edited #2583

Version: fresh 0.4.3 (built from origin/master @ 9f6135001)

The 0.4.2 "Step through Search & Replace matches from the editor" feature (#2434) exists explicitly "so you can review or edit it" at each stop — but the panel's match positions are recorded once at search time and never adjusted for buffer edits. After any edit that shifts text (a line inserted/deleted above a match, or characters inserted before a match on its own line), every subsequent Ctrl+Alt+→ / Ctrl+Alt+← step (and Enter-open on a panel row) in that buffer moves the cursor to the old line/column, landing on unrelated text instead of the match.

Everything else about the feature works well (verified in the same session): forward/backward stepping, wrap-around in both directions, cross-file opening in the source split, focus landing in the editor for immediate editing, the panel list highlight following the current match, the palette commands ("Next/Previous Search Match"), and the graceful "No Search & Replace results — run a search first" message when no search is active.

Steps to reproduce

1. Create a small git project: alpha.txt containing

   first line plain
   NEEDLE one here
   middle text
   another NEEDLE two
   tail line
   

   (plus any other files with NEEDLE matches).
2. fresh --no-restore alpha.txt
3. Alt+A, type NEEDLE → matches listed (e.g. alpha.txt:2, alpha.txt:4, …).
4. Ctrl+Alt+→ → status Match 1/5, cursor lands on line 2, col 1 — correct.
5. Edit the buffer: press Up, Home, type inserted row, press Enter. The second match ("another NEEDLE two") is now on line 5.
6. Ctrl+Alt+→.

Column variant: on a match line, press Home, type xx (match now starts at col 3), step away (Ctrl+Alt+→) and back (Ctrl+Alt+←).

Enter-open variant: after step 5, focus the panel and press Enter on the (now stale) alpha.txt:2 row.

Expected behavior

The cursor lands on the match's current position (line 5, col 9). In VS Code, search results are anchored to the live document: editing above a result shifts the result, and clicking it or stepping to it lands on the actual match. This matters doubly here because the feature's own purpose (per the 0.4.2 changelog) is to edit at each match while stepping — the first line-count-changing edit makes every later stop in that file wrong.

Actual behavior

• Step 6: status shows Match 2/5 at Ln 4, Col 9 — the cursor is physically on line 4 ("middle text"), the pre-edit position, while the match is on line 5. Verified by the real terminal cursor cell (tmux #{cursor_x}/#{cursor_y}), not just the status bar.
• Column variant: cursor returns to col 1 (on the x), while the match now starts at col 3.
• Enter-open variant: same stale landing (cursor on "first line plain" instead of the shifted "NEEDLE one here").
• The panel's list rows and previews also keep the stale line numbers/text until a manual re-search.
• Matches in unedited files keep landing correctly — the staleness is per edited buffer.

Workaround

Re-run the search after editing: Alt+A (focus the Search field) then Enter — the list refreshes with correct positions and stepping lands correctly again.

Duplicate-check queries used: "search replace stale position", "search results after edit wrong line", "match list outdated buffer edit", "next search match step" — no existing report found (#2414 covers phantom highlights after plugin-driven replace, a different defect).