fix: force preview for protected files regardless of background editing

[roomote]

Summary

This PR fixes an issue where protected files (like .vscode/, .roo/, etc.) could be edited without preview when the "Background editing" experimental feature is enabled. This was a security concern as these configuration files should always require explicit approval before modification.

Problem

When the PREVENT_FOCUS_DISRUPTION experiment (Background editing) is enabled, the file editing tools would bypass the diff view and directly save changes to files. This behavior was applied to all files, including protected configuration files, which should always require preview and explicit approval.

Solution

Modified all file editing tools to check if a file is write-protected and force the diff view regardless of the background editing setting:

• writeToFileTool: Added condition to check !isWriteProtected before using direct save
• applyDiffTool: Same fix applied
• insertContentTool: Modified to show diff view when file is protected
• searchAndReplaceTool: Modified to show diff view when file is protected
• multiApplyDiffTool: Added protection checks for both single and batch operations

Testing

Added comprehensive test coverage in writeToFileTool.spec.ts to verify:

• Protected files always show diff view even with background editing enabled
• Non-protected files still use direct save when background editing is enabled
• The isProtected flag is correctly passed to approval dialogs
• Protection works for various protected file patterns (.vscode/, .roo/, etc.)

All existing tests pass, confirming no regression in functionality.

Related Issue

Fixes #6722

---

Important

This PR ensures protected files always require a diff view for approval, even with background editing enabled, by modifying several file editing tools.

• Behavior:
  • Forces diff view for protected files in writeToFileTool, applyDiffTool, insertContentTool, searchAndReplaceTool, and multiApplyDiffTool regardless of background editing setting.
  • Non-protected files continue to use direct save when background editing is enabled.
• Testing:
  • Added tests in writeToFileTool.spec.ts to ensure protected files always show diff view.
  • Tests verify behavior for .vscode/ and .roo/ files.
  • Tests confirm isProtected flag is passed to approval dialogs.
• Misc:
  • Fixes [BUG] Unable to preview edits to protected files before save when Background editing is enabled #6722.

^{This description was created by for fb30e4e. 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 backward but the bugs are still mine.

[roomote]

Is this intentional? The condition for checking protected files in batch operations uses a different pattern than the other tools. Consider refactoring to match the pattern used elsewhere for consistency:

Suggested change

	if (isPreventFocusDisruptionEnabled && !hasProtectedFiles) {
	if (isPreventFocusDisruptionEnabled && !isWriteProtected) {

[roomote]

The comment 'only for non-protected files' appears multiple times across the codebase. Could we improve readability by extracting this logic into a well-named variable like shouldUseDirectSave? This would make the intent clearer and reduce repetition.

[roomote]

This test suite is quite comprehensive! However, it might benefit from being split into smaller, more focused describe blocks. For example, you could have separate blocks for 'direct save behavior', 'diff view behavior', and 'protection flag handling'. Also, consider adding a test case for when rooProtectedController is undefined/null to ensure the fallback to false works correctly.

[daniel-lxs]

I feel like this defeats the purpose of background edits, background edits is an experimental feature that depends on another pending feature to be complete.

I'll close this for now but feel free to continue the discussion.