[thatdaveguy1]

Why

The account database and active auth file are written directly today. If the app crashes mid-write or multiple operations overlap, that can leave accounts.json or auth.json in a partially written state.

This PR hardens those persistence paths with atomic writes, simple locking, and backup files so storage updates are more crash-resistant.

What changed

• add shared filesystem helpers in fs_utils.rs for locked atomic writes
• update storage.rs to use the new write path for account persistence
• update switcher.rs to write active auth data atomically and emit .bak backups
• ensure lockfile parent directories are created for first-run paths

Reviewer notes

• this PR is intentionally limited to persistence safety
• backup security mode selection and process restart behavior are handled in separate PRs

Verification

• cargo check in src-tauri passes on this branch

---

Maintenance triage — 2026-09-30

Continue in: #182.

Atomic persistence and cross-process single-writer work is consolidated in #159 / #182. The previous stale lockfile and unused .bak recovery concerns remain documented in this PR's review. #182 is the current implementation to review; neither this closure nor #182 repairs an already-corrupted store.

[Lampese]

plz resolve the conflicts

[Lampese]

Requesting changes for two behavioral issues:

1. The new .lock file approach can deadlock future writes after a crash. FileLock creates a sibling lock file with create_new(true) and only removes it in Drop. If the process is killed or crashes after acquiring the lock, the stale .lock file remains behind permanently, and every later write path will just time out waiting for it. That means the crash-hardening path introduces a new failure mode exactly in the scenario this PR is trying to improve.

2. The new .bak files are written, but none of the read paths actually use them for recovery. accounts.json.bak and auth.json.bak are created, but loading still reads only the primary file and fails immediately if it is corrupted or partially unreadable. So the backup mechanism currently increases file churn without providing an actual recovery path.

I think both issues should be addressed before merging, otherwise this change improves write atomicity but still leaves crash recovery incomplete and can also introduce stale-lock write failures.