Archive a settings file that fails to deserialize instead of deleting it [patch]

[matt-edmondson]

Fixes #314

What was wrong

When AppData<T>.LoadOrCreate hit a JsonException, it deleted the main file and retried. A successful save removes the .bk file, so in practice that file was the only copy of the user's data. Two ordinary events triggered this, and nothing was logged or left on disk afterwards:

• a trailing comma left by a hand edit
• a model change in an app update, such as a renamed enum member

Change

• The counter loop from TryRestoreFrom is now AppData.Archive(filePath, label), which returns the path it archived to. TryRestoreFrom uses it with no label, so its behaviour is unchanged.
• LoadOrCreate archives the unreadable file to <file>.corrupt.<yyyyMMdd_HHmmss> instead of deleting it. The retry still finds the main file missing and falls back to the temp file, then the backup, then defaults.
• The misleading "delete and try load a backup" comment is corrected, and so is the TryRestoreFrom comment that described the old delete.
• This PR does not expose the archived path as an event or property, which the issue listed as optional. The triage comment suggested that come in a separate change.

Tests

• New test TestLoadOrCreateArchivesAnUnreadableFileInsteadOfDeletingIt follows the issue's repro: save real data, break the JSON, then LoadOrCreate. It asserts the defaults load and exactly one .corrupt.* archive holds the original content. With the delete restored, it fails at Assert.AreEqual(1, archived.Length).
• Full suite: 109/109 passed locally, including TestLoadOrCreateHandlesCorruptFile and the recovery tests.

🤖 Generated with Claude Code

https://claude.ai/code/session_01DCzUAHg8icJNNp7WtR51Um

---

Generated by Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud