feat: add fuzzy text matching fallbacks for edit_file tool

[trungutt]

Summary

Inspired by the resilient edit matching in OpenCode (which uses 8+ fallback strategies in its edit tool), this adds fuzzy text matching to edit_file.

When an exact oldText match fails, the tool now tries progressively looser normalization strategies before returning an error:

1. Line-trimmed — strip trailing whitespace per line
2. Indentation-flexible — strip leading whitespace per line
3. Line-continuation normalization — collapse \ + newline + spaces into a single space
4. Escape-normalized — treat \" and " as equivalent
5. Whitespace-collapsed — collapse all whitespace runs to a single space

These handle real-world LLM mistakes observed in session logs:

• Adding spurious indentation to oldText (e.g., 4 leading spaces on a Dockerfile RUN line)
• Collapsing multi-line shell continuations (\ + newline) into single lines
• Unescaping \" to " when reproducing file content

When a fuzzy strategy matches, the replacement is applied to the original (un-normalized) content so surrounding text is preserved exactly. Index mapping between normalized and original strings uses binary search with rune-aware boundary snapping to preserve UTF-8 integrity.

Both the builtin and ACP filesystem handlers use the shared FindAndReplace function.

This PR is independent of #2144 (double-serialized edits fix).

[docker-agent]

Review Summary

Assessment: 🔴 CRITICAL

This PR adds fuzzy text matching fallbacks to the edit_file tool with 6 normalization strategies. The implementation has critical bugs in the boundary mapping logic that can cause data corruption when fuzzy matching is triggered.

Critical Issues Found

2 HIGH severity bugs in the mapNormToOrigEnd function that handles boundary detection for character-consuming normalizations (whitespace collapsing, line continuations, etc.). These bugs can lead to incorrect replacement ranges and file corruption.

1 MEDIUM severity issue in the binary search logic that may cause off-by-one errors with collapsing normalizations.

Recommendation

The boundary mapping algorithm needs to be redesigned or thoroughly tested with edge cases involving:

• Multi-byte UTF-8 characters combined with character-consuming normalizations
• Whitespace collapsing at UTF-8 boundaries
• Line continuation normalization with non-ASCII content

The existing test suite does not cover these critical edge cases.

---

Detailed Findings

See inline comments below.

[docker-agent]

🔴 HIGH: Incorrect termination condition for consumed character detection

The condition len(normalize(original[:pos+size])) != len(normalize(original[:pos])) is fundamentally flawed for character-consuming normalizations.

The Problem:
When normalization collapses multiple characters to fewer (e.g., collapseWhitespace, collapseLineContinuations), advancing by one rune will almost always change the normalized length UNLESS that rune is completely consumed. This logic will fail to correctly identify the end boundary.

Impact:

• Wrong replacement ranges
• Potential file corruption when fuzzy matching triggers
• Especially dangerous with multi-byte UTF-8 characters

Example:
Consider normalizing "a b" (two spaces) to "a b" (one space):

• At position after 'a', normalized length is 2
• Advancing one rune (first space), normalized length is still 2 (space collapsed)
• Advancing another rune (second space), normalized length is still 2
• The loop will incorrectly continue past the intended boundary

The test suite doesn't cover these edge cases with UTF-8 and character-consuming normalizations.

[docker-agent]

🔴 HIGH: mapNormToOrigEnd boundary detection logic is incorrect

This function attempts to advance past trailing characters consumed by normalization, but the implementation is fundamentally incorrect for normalizations that map multiple characters to fewer.

Root Cause:
The function uses mapNormToOrig (binary search) to find the starting position, then advances by runes while checking if the normalized length changes. However, this approach doesn't correctly handle character-consuming normalizations like:

• collapseWhitespace (multiple spaces → one space)
• collapseLineContinuations (\\ + newline → space)
• normalizeEscapedQuotes (\\" → ")

Impact:
Incorrect end boundary detection leads to wrong replacement ranges and potentially corrupted file content.

Recommendation:
Consider a different approach:

1. Track character-to-character mapping during normalization
2. Use a forward scan with explicit state tracking
3. Add comprehensive tests with UTF-8 edge cases

[docker-agent]

🟡 MEDIUM: Binary search may overshoot with collapsing normalizations

The binary search finds "the smallest position where the normalized prefix has at least normIdx characters", but this can cause off-by-one errors when normalization collapses characters.

Example:
Normalizing "a b" (two spaces) to "a b" (one space):

• Looking for position 2 in normalized string (after "a ")
• Binary search might land at position 3 in original (after "a ")
• Because normalize("a ") = "a " has length 2

Why LIKELY not CONFIRMED:
The binary search invariant appears correct in principle, but edge cases with collapsing normalizations could expose boundary issues. The real problem is that this function feeds into mapNormToOrigEnd, which has confirmed bugs.

Recommendation:
Add test cases specifically for boundary detection with:

• Multiple consecutive collapsible characters
• UTF-8 multi-byte characters adjacent to collapsible sequences

[trungutt]

Closed, reopen when needed