Write the desktop settings store owner-only

[GeiserX]

TL;DR

settings.json holds a remote server's credential and was created world-readable. serverProfiles carries the bearer token or basic-auth password for any "Custom server" the user connects to. conf (under electron-store) defaults to configFileMode: 0o666, so with no explicit mode the file lands 0644.

One line: configFileMode: 0o600 on the Store constructor.

Scope, stated honestly: this is primarily a Linux-desktop exposure. macOS is protected by ~/Library being 0700 and Windows by ACLs on %APPDATA%. It is still worth fixing, because owner-only credential files are already this app's own standard — local-auth.ts (which settings.ts imports) writes auth.json at 0o600 plus a chmod, and the sidecar manifest is chmodded the same way. This store was the outlier.

---

Why one option and not the mode-plus-chmod pair used elsewhere

atomically chmods the temp inode only when the requested mode differs from its own default, and the atomic rename then carries the tight mode onto an already-loose file. So setting the option is what turns that chmod on, and no follow-up chmodSync is needed.

I did not want to take that on trust, so I measured it against the installed conf:

case	resulting mode
no option, fresh file	0644
configFileMode: 0o600, fresh file	0600
configFileMode: 0o600, file already 0644	0600

The third row is the one that matters for existing installs: a settings.json written by an earlier build is tightened on the next write rather than staying loose forever.

Tests

settings-permissions.test.ts — three of them, driving the real electron-store with the exact
options settings.ts passes:

• a fresh store is created 0600;
• an existing 0644 store is tightened on rewrite — the half that would silently not happen if the
  single option did not trigger atomically's chmod;
• the control: without the option, the file really is world-readable. Without that, the first two
  would pass just as happily on a machine with a restrictive umask and prove nothing.

Mutation-checked: setting the option to 0o666 fails the first two and leaves the control green.

This pins the load-bearing part — the claim that one option is enough here, where the rest of the
app uses a mode-plus-chmod pair, because atomically chmods the temp inode and the rename carries the
tight mode onto an already-loose file. A claim about a transitive dependency is worth checking rather
than repeating.

What it deliberately does not bind is the wiring in settings.ts itself. That module builds its
store at module scope and pulls in electron, which cannot be imported outside an Electron runtime,
which is why the desktop package has no settings.test.ts (main/ has tests for
supervised-connection, supervised-daemon and updater-state, and nothing for settings). Mocking
electron-store away would leave the test asserting the mock rather than the behaviour in question, so
the option is verified against the real dependency and the wiring is left uncovered on purpose.

[GeiserX]

Context for this one: #1585 explains why this PR and the others in the series exist — they came out of a single pass over credential handling, asking for each credential where it ends up, how long it stays, and who can read it once it's there.

This PR stands alone and doesn't depend on any of the others.