Fix: a new install no longer resets settings the user changed

[thcp]

Confirmed, reproduced, fixed

Reproduced against the published 0.14.0 package, not a local build:

OLD install: user relocates the stems folder
    before : C:\Users\thale\Documents\StemDeck\jobs
    after  : ...\repro\MyStems
    settings.json jobs_dir -> ...\repro\MyStems

NEW install (fresh extract of the SAME release):
    reports: C:\Users\thale\Documents\StemDeck\jobs
    new install has settings.json: False

The library looks empty even though every stem is still on disk where the user put it.

Cause

Portable packages keep their data in <app>/data (#399), so settings.json lives inside the install directory. A new install is a new folder, so it starts with an empty data/ and loses everything the user set — not just the stems location, but the port, compute device, separation quality and language too.

The restore half was already in the working tree: migrate_persisted_files plus an ensure_workspace step that seeds a freshly extracted portable package from a per-user copy. What was missing was anything writing that copy. Nothing had, since #399 moved the data directory out of %LOCALAPPDATA% and no writer took over the old location — so the restore was reading a path that never existed. On this machine %LOCALAPPDATA%\StemDeck did not exist at all.

The write half

• shared_settings_dir() names the per-user location once, for all three platforms. Deliberately the OS-standard data dir — exactly what local_data_dir() returns for a non-portable install — so both layouts share one location and an install that switches between them keeps its settings.
• start_backend passes it as STEMDECK_SETTINGS_MIRROR, so the writer and ensure_workspace's reader cannot drift apart.
• settings._save() mirrors there after each successful write. Best-effort by construction: it is a redundant copy and must never fail the setting the user just changed. Written via temp-file-and-replace, because a torn write would be restored verbatim into the next install.

Verified

End to end against the source backend — same scenario that reproduced the bug:

==> per-user copy written? True
    jobs_dir in copy: ...\verifyfix\MyStems
==> shell seeds the fresh install (what ensure_workspace does)
==> NEW install, started clean
    reports: ...\verifyfix\MyStems
RESULT: PASS - the new install kept the user's stems folder

Five tests cover the write half, including that a mirror which cannot be written still saves the setting, and that the mirror tracks later changes (a stale copy would hand back a setting the user had already changed — the same class of bug as losing it).

	Windows	Linux
clippy	clean	clean
rust tests	45	46
rustfmt	clean	—

Python: ruff clean, and no new failures — identical 14 pre-existing Windows-environment failures on main and this branch.

Also included

The clippy cleanups already sitting in the working tree (derivable Default, match to if let, redundant trim, unneeded return, unused binding) — audit item F12. Mechanical, and both platforms compile with zero warnings.

Note on scope

This fixes the manual upgrade path, which is what was reported. The in-app updater added in #423 never had this problem: it replaces backend/ and the executable while leaving data/ untouched, so settings already survive that route.