Fix settings refresh lag / 优化设置保存响应

[GTC2080]

Problem

Fixes #4663.

After the v1.9.0 desktop/global config path consolidation, Settings saves could feel delayed even for lightweight UI-only actions such as display mode, status bar, or appearance changes.

The provider/MCP visibility side of this report is covered by the synced main-v2 migration work. This PR focuses on the remaining Settings interaction lag.

Root Cause

SettingsPanel reloaded app.Settings() after every save, then notified the parent with a generic onChanged() callback. Because the parent did not receive the freshly loaded SettingsView, it immediately performed additional full app.Settings() reads to refresh desktop preferences and the IM sidebar.

That made a single Settings save perform redundant config reads on the critical UI path. Those reads now include global/project config merge and provider credential projection, so the extra work is visible as a small but noticeable "half beat" after clicking Settings controls.

Fix

• Return the normalized post-save SettingsView from the panel reload path.
• Pass that snapshot through onChanged(settings) after foreground and background Settings mutations.
• Reuse the snapshot in App to refresh desktop preferences and IM sidebar state without re-reading full Settings.
• Keep the no-snapshot fallback for Settings pages such as Hooks that manage their own data.
• Add a jsdom regression test that verifies a Settings save sends the post-save snapshot and keeps Settings reads bounded.

Cache impact

None. This is desktop Settings refresh plumbing only. It does not change provider request serialization, prompt prefixes, tool schemas, model resolution, or chat cache-sensitive surfaces.

Verification

• corepack pnpm exec tsx src/__tests__/settings-refresh-snapshot.test.tsx
• corepack pnpm run test:all
• corepack pnpm run build
• go test ./...
• cd desktop && go test ./...
• go vet ./...
• cd desktop && go vet ./...
• gofmt -l .
• git diff --check