Pre-release Opus review of v0.50.250 caught a UX regression in PR
#1369: _autosavePreferencesSettings unconditionally cleared
_settingsDirty=false and hid the unsaved-changes bar on every
successful autosave. But password and model are still committed via
the explicit 'Save Settings' button (password for security; model
goes through /api/default-model). Race scenario:
1. User opens System pane, types a new password (sets
_settingsDirty=true; bar appears on close)
2. User switches to Preferences, toggles any checkbox -> autosave
fires -> _settingsDirty=false, bar permanently suppressed
3. User closes panel -> _closeSettingsPanel short-circuits because
!_settingsDirty -> typed password silently discarded
(loadSettingsPanel blanks pwField.value='' on next open)
Same shape with model selector: pick a new default model, then
toggle any preference -> autosave fires -> no warning on close ->
model never persists.
Fix: only clear _settingsDirty and hide settingsUnsavedBar when both
the password field is empty AND the model selector matches its
on-open snapshot.
Pinned by an updated regression test asserting the conditional guard
exists.
9 source-level invariants covering #1369:
- All 13 preference fields appear in _preferencesPayloadFromUi
- Listeners use _schedulePreferencesAutosave, not _markSettingsDirty
- Password field STILL uses _markSettingsDirty (security invariant)
- _autosavePreferencesSettings clears _settingsDirty + hides unsaved bar on success
- Status div present in static/index.html
- Status function uses shared i18n keys from Phase 1
- Retry function falls back gracefully when no stored payload
- Debounce clears prior timer (350ms, matching Phase 1)
- Phase 1 (Appearance) autosave still intact
