Keep display preferences per-browser, and remember each user's view - #2332

Problem

Dashy holds two copies of the config in the Vuex store:

• state.config — what's rendered right now
• state.configSource — what gets written back to conf.yml, and is therefore shared by every user of the instance

The quick-pickers for theme, layout and item size wrote to both, plus localStorage. Nothing looks wrong until someone saves: Save to Disk, from the config editor or the "You're using a local config" banner, serialises configSource — which by then carries whatever theme, layout and item size that user happened to be viewing with. Those land in the shared conf.yml. On success carefullyClearLocalStorage() drops their local override, so the value is now purely file-backed, and every other user (having no override of their own) falls back to the file and inherits it.

The result: on a shared instance, one person changing their theme and saving any unrelated config edit silently changes the theme for everybody.

Separately, the view (default / minimal / workspace) had no per-browser persistence at all. theme, layout, iconSize and language are all remembered per browser via configScope() / readLocalOverrides(), but the view is resolved by the router's beforeEnter guard reading appConfig.startingView directly, before that local-override layer is ever consulted. So users sharing an instance could each keep their own look, but not their own view.

Changes

Two commits, reviewable independently.

1. Keep personal display preferences out of the shared config — src/store.js, +8/-3

patchAppConfigField already receives a storageKey, and it is passed only by the personal quick-pickers (SET_THEME, SET_ITEM_LAYOUT, SET_ITEM_SIZE, SET_LANGUAGE); authored edits such as UPDATE_CUSTOM_CSS pass nothing. That existing argument becomes the discriminator — when present, update state.config and localStorage, then return without touching configSource:

state.config = { ...state.config, appConfig: { ...state.config.appConfig, [key]: value } };
if (storageKey) {
  localStorage.setItem(storageKey, value);
  return;
}
state.configSource = { ... };

Rendering is unchanged — the getters read state.config. Authoring an instance-wide default from the interactive editor is unchanged too, since theme, layout and iconSize getters already bypass localStorage while state.editMode is on.

2. Remember the view each user picks, per browser — +49/-17

• defaults.js: new localStorageKeys.STARTING_VIEW ('startingView')
• ConfigHelpers.js: resolveStartingView(stored, configured) and rememberStartingView(view), next to the existing VIEW_META; clearScopedLocalConfig() removes the key
• router.js: the landing guard consults the stored pick first, then appConfig.startingView, then home
• OptionsPanel.vue and ViewSwitcher.vue: both view switchers record an explicit pick

Only an explicit pick from a switcher is stored, so following a link or bookmark to /minimal doesn't quietly rewrite someone's landing view. An unrecognised stored value falls through to the configured value rather than breaking routing, and Config → Reset Local Settings clears it alongside the existing theme and layout overrides.

Behaviour

Compatibility

No config format change. Existing conf.yml files work untouched, appConfig.startingView still sets the default for anyone who hasn't picked a view, and the legacy default alias for home is still accepted. The new localStorage key is additive, and its absence is the pre-existing behaviour.

Testing

Verified manually against a running instance, in two browser profiles:

• A user's theme survives a reload, and is not visible in a second profile
• With a theme picked, Save to Disk writes conf.yml with the authored theme intact — the viewing user's choice does not appear in the file
• A fresh visitor lands on appConfig.startingView; after picking Minimal, / lands on /minimal for that browser only, while a second profile still lands on the configured view
• Reset Local Settings returns both the theme and the view to the config's values

Each of the two behaviours was also confirmed to regress when its change is reverted, so the checks above distinguish the fix from the prior behaviour rather than passing either way.

Existing suite: 536 tests pass, lint clean.