fix: stop duplicating surrounding code in inline chat diffs

[laileni-aws]

Problem

When inline chat is invoked with the cursor on a blank line (no selection) inside a function, the returned diff re-inserts the entire enclosing method with the new code inside it. Accepting the diff duplicates the lines that already exist above and below the cursor, and the inserted block is mis-indented compared to the surrounding code.

Root cause: InlineTask treats the cursor's (empty) line as the selected text, while the model is given the surrounding code as context and typically answers with the whole enclosing block. computeDiff then diffs the full response against an empty string, so every line—including code that already exists—becomes an insertion. The first line's indentation is also re-based on the empty selection, so it lands at column 0 while later lines keep the model's indentation.

Solution

Before diffing a complete response, anchor it against the document:

• Find the longest run of response lines (from the start) that matches the document lines directly above the selection, and the longest run (from the end) that matches the lines directly below it. Matching ignores indentation.
• Widen the task's selection to cover those lines so they diff as unchanged; only the genuinely new lines are shown as an insertion.
• Re-indent the response so its anchored lines line up with the matching document lines.
• If nothing is echoed and the selection is blank, keep the response's own indentation for every line instead of stripping the first line's indent.

Partial (streaming) diffs are left as-is and are corrected when the final response is applied. Behavior for non-empty selections whose response does not repeat surrounding code is unchanged.

Adds unit tests for anchorResponseToDocument and computeDiff covering: echoing the enclosing method with an empty selection, re-indentation, one-sided overlap, no overlap, blank-line trimming, non-empty selections, partial responses, and a regression check for a plain selection rewrite.

---

• Treat all work as PUBLIC. Private feature/x branches will not be squash-merged at release time.
• Your code changes must meet the guidelines in CONTRIBUTING.md.
• License: I confirm that my contribution is made under the terms of the Apache 2.0 license.