Critical hotfix for the 0.17.0 regression: users upgrading from 0.16.x
were logged out, and their next login wrote a fresh empty secure-store
on top of the original ciphertext — destroying device keys irrecoverably.
Why it happened: loadState used a blanket `catch {}` that conflated
"file doesn't exist (genuine new user)" with "file exists but can't be
decrypted (DPAPI / OSCrypt quirk after the install rename)". Both paths
returned an empty Map; the next scheduledSave then overwrote the
original .bin file with a fresh blob.
Fix:
* Separate ENOENT from decrypt/parse failures. ENOENT → empty Map. Any
other read error → log, empty Map (no quarantine, matches old
behaviour for transient lock issues).
* When decrypt/parse fails the original file is renamed to
<file>.broken-<iso-ts> BEFORE returning empty Map. The next save
writes to a fresh file; the original ciphertext is preserved on disk
so a future build (or manual recovery) can still get at the bytes.
* Loud console.error around the failure so future regressions surface
in main-process logs.
main.ts: move setPath('userData', appData/ChatApp) BEFORE setName so
any productName-derived path caching inside setName can't beat us to
it. Add a startup log of the resolved paths so future debugging has
hard evidence instead of guessing.
Affected users on 0.17.0 should still recover via Settings → Backup
Wiederherstellen (account-level keys are unchanged); this fix prevents
the data destruction for anyone who hasn't upgraded yet.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>