fix: prevent false unsaved changes notification when mode/API changes externally

[roomote]

Description

This PR fixes issue #7417 where users were incorrectly prompted about unsaved changes when:

1. They changed the mode or API configuration in the main interface
2. Then opened the Settings dialog
3. And closed it without making any changes

Problem

The Settings dialog was incorrectly detecting external changes (mode/API config changes from the main interface) as internal changes, causing a false positive "unsaved changes" warning.

Solution

Added logic to detect and handle external changes separately from internal settings changes:

• External changes to mode or API configuration now update the cached state without marking settings as dirty
• Only changes made within the Settings dialog itself trigger the unsaved changes warning
• Added a new useEffect hook that monitors for external state changes and syncs them without triggering change detection

Testing

• All existing tests pass
• Manually tested the scenario described in the issue to confirm the fix works

Related Issue

Fixes #7417

---

Important

Fixes false unsaved changes notification in SettingsView.tsx by correctly handling external mode/API changes.

• Behavior:
  • Fixes false unsaved changes notification in SettingsView.tsx when mode/API changes externally.
  • External changes update cached state without marking settings as dirty.
  • Only internal changes in the Settings dialog trigger unsaved changes warning.
• Implementation:
  • Adds useEffect hook in SettingsView.tsx to monitor and sync external state changes without triggering change detection.
• Testing:
  • All existing tests pass.
  • Manually tested the scenario described in issue Invalid notification of "Unsaved Changes" #7417.

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

[roomote]

Reviewing my own code because apparently I trust no one, not even myself.

[roomote]

Is this intentional? The condition isExternalChange && !isChangeDetected could lead to race conditions if internal changes happen simultaneously with external changes. Consider using a more robust state management approach or a ref to track the source of changes.

[roomote]

Using JSON.stringify for deep comparison on every render could be expensive for large API configurations. Could we use a more efficient deep comparison utility like lodash's isEqual or memoize this comparison?

Suggested change

	JSON.stringify(extensionState.apiConfiguration) !== JSON.stringify(cachedState.apiConfiguration)
	JSON.stringify(extensionState.apiConfiguration) !== JSON.stringify(cachedState.apiConfiguration)

[roomote]

The code only checks for mode and apiConfiguration changes, but other fields could also change externally (e.g., language, experiments). Should we expand this to cover all fields that could change externally, or is there a specific reason to limit it to these two?

[roomote]

There are now three separate places handling similar logic for setChangeDetected(false) (lines 200, 208, and within the new effect). Could we consolidate this logic into a single helper function or custom hook to improve maintainability?

[daniel-lxs]

Closing this PR as it addresses the symptoms but not the root cause. The real issue appears to be that something in the configuration object (particularly with OpenRouter APIs) is changing unexpectedly or not being saved properly, which triggers the dirty state incorrectly. We need to investigate the actual root cause instead of masking the problem.