Harden save/export persistence with atomic writes and proper app data directories

[JakenHerman]

Summary

Save files and HTML exports are currently written directly to their final destination, and default storage paths are derived from HOME or the current working directory.

Why this matters

Direct writes can leave truncated or corrupt files if the process is interrupted mid-write. The current directory fallback is also fragile, especially for the Windows release path already advertised in the project README.

Current examples

• persist::write_save_file() uses fs::write() directly to the final save path.
• export::export_html() uses fs::write() directly to the final export path.
• Save/export directories are built from HOME with a fallback to current_dir().

Acceptance criteria

• Saves and exports are written atomically via a temp file + rename strategy, or an equivalent crash-safe approach.
• Partial writes do not replace a previously good save/export file.
• Default app data locations use an OS-appropriate strategy on macOS, Linux, and Windows.
• Error messages remain user-friendly when directory creation or writes fail.
• Add tests for the path-resolution helpers and any new persistence helpers where practical.

Notes

This does not need full cloud sync or backup support; the goal is reliable local persistence for released binaries.