feat: configurable database and backup location (sync-folder friendly)

[obeidahmad]

Problem / motivation

The database location is hardcoded: monay.db resolved relative to the current working directory (sqlite:///monay.db in monay/bootstrap.py / monay/__main__.py). The user can't choose where their data lives. This blocks the simplest, zero-infrastructure form of cloud backup: if the user could point their data — or at least their backups — at a folder that a sync client already watches (OneDrive, Google Drive, iCloud Drive, Dropbox), they'd get offsite, versioned, cross-device copies for free, with Monay running no servers and storing nobody's data.

Proposed solution

Make the storage location configurable, with sync-folder use as the headline case.

• A persisted setting for where monay.db lives and where backups/ lives (the rotating snapshots from feat: rotating snapshot backups with in-app restore #44). Allow them to be set independently.
• Store the setting in a small config file in a standard per-user location (the platformdirs dependency is already available) so it's independent of the working directory.
• Let the user set these from the app (the Settings tab exists, monay/tui/screens/settings.py) and/or an env override for power users.
• On startup, resolve the configured paths, creating the directories if needed, and fall back to the current default when unset.

Pointing backups/ (or the DB) at a OneDrive/Drive/iCloud/Dropbox folder is then just "choose that folder" — the OS sync client does the uploading.

Important caveat: a live SQLite DB in a synced folder is risky

This needs to be designed in, not discovered later. Continuous file-sync clients can copy a SQLite database mid-write (especially with WAL journaling) or create "conflicted copy" duplicates if the app is open on two machines — a well-known footgun (e.g. Dropbox + SQLite).

• Static snapshots are safe to sync — they're never written after creation.
• The live DB is not — syncing it while in use risks corruption or conflict copies.

Recommended default guidance: point only backups/ at the synced folder and keep the live DB local. Users who insist on the DB itself in a synced folder can, but should be warned to run Monay on one machine at a time.

Relationship to other recovery work

• feat: rotating snapshot backups with in-app restore #44 (rotating snapshots): this issue is what makes those snapshots offsite. Snapshots are the safe-to-sync artifact.
• feat: single-level undo for destructive operations #45 (undo): unrelated — local, per-action recovery.

Alternatives considered

• Built-in upload to S3 / a private git repo. More automation and control, but Monay then owns credential handling, retries, and failure modes. Heavier than letting an existing sync client do the work; revisit only if "use a synced folder" proves insufficient.
• A hosted Monay service (accounts + server-side storage + multi-device sync). A different product, not a feature: servers, auth, uptime, and liability for other people's financial data. Out of scope for a local-first app.
• Encryption of synced files. Out of scope for this issue but worth a follow-up — anything leaving the machine ideally is client-side encrypted, since this is financial data and the sync provider would otherwise see plaintext.

Notes / scope

• No app-level config file exists yet; this introduces one. Keep it minimal (paths first).
• Moving an existing DB to a new configured location needs a defined behaviour (move the file vs. start fresh there).