fix: add type check before calling .match() on diffItem.content (#6905)

[roomote]

Fixes #6905

Problem

The application was throwing a runtime error "v.content.match is not a function" when attempting to apply diffs. This occurred when diffItem.content was not a string (could be null, undefined, or another type), but the code was calling .match() on it without type checking.

Solution

Added a type check to ensure diffItem.content is a string before calling .match() method on it. This prevents the runtime error and allows the diff application to handle non-string content gracefully.

Changes

• Added typeof diffItem.content === 'string' check in src/core/tools/multiApplyDiffTool.ts before calling .match()
• Created comprehensive test suite in src/core/tools/__tests__/multiApplyDiffTool.spec.ts to verify the fix handles:
  • undefined content
  • null content
  • numeric content
  • mixed content types in diff arrays
  • proper counting of SEARCH blocks for valid strings

Testing

• All new tests pass ✅
• All existing tests pass with no regression ✅
• Linting and type checking pass ✅

---

Important

Adds type check in applyDiffTool() to prevent runtime errors when diffItem.content is not a string, with comprehensive tests for various content types.

• Behavior:
  • Adds typeof diffItem.content === 'string' check in applyDiffTool() in multiApplyDiffTool.ts to prevent runtime errors when diffItem.content is not a string.
  • Handles non-string diffItem.content gracefully by skipping invalid entries.
• Testing:
  • Adds tests in multiApplyDiffTool.spec.ts to verify handling of undefined, null, numeric, and mixed content types.
  • Tests ensure proper counting of SEARCH blocks for valid strings.
  • All new and existing tests pass without regression.

^{This description was created by for 55f0ab1. You can customize this summary. It will automatically update as commits are pushed.}

[roomote]

Reviewing my own code is like debugging in a mirror - everything looks backwards but the bugs are still mine.

[roomote]

Good defensive programming here! Though I wonder - should we also add a similar type check in the legacy applyDiffTool.ts at line 234? While it's currently protected by earlier validation, adding the same defensive check would ensure consistency and future-proof the code.

Also, is there a reason we're not checking for the same issue in the earlier loop around line 420 where we process diff items?

[daniel-lxs]

LGTM

It would be good to find out why this tool is returning content as something other than a string.

@samhvw8