[RayTrunk]

Closes #71.

Problem

Attachment and file downloads always open the folder the platform suggests, with no way to change it. Every save dialog is built in one place, DocumentDialog::file_dialog in src/documents.rs, and it never called set_directory.

Solution

Settings.download_directory stores the folder, and Settings → General gains a Download location card to pick one or reset to the platform default.

The stored path is resolved when a download is saved, not when the path is stored. A location can become unavailable later — an unmounted network share, a removed drive — so resolve_download_directory falls back to the platform default for an empty setting, a path that no longer exists, or a path that is not a directory. A download never fails because a saved location went away.

Scope:

• Covered: mail attachments (attachment_controller.rs) and the Files view (files_controller.rs), which share DocumentProvider::export. Both go through download_dialog_for, so a future download site picks the location up without repeating the lookup.
• Not covered: import dialogs keep the platform default, since a download location does not describe where files are read from.
• Desktop only: the card is hidden unless download_directory_available is set, which startup.rs ties to cfg!(desktop). Mobile hosts export through their own document provider and have no filesystem directory to offer.

User-visible effects

• A Download location card in Settings → General, below Renderer, reachable through the settings search (download, location, folder, attachments).
• Save dialogs open in the chosen folder. The dialog is not skipped, so only its starting point changes.
• Before an account exists the card reports Download location is saved once an account is set up., matching how set_theme_preset handles session-only settings.

Tests

In src/documents.rs:

• configured_directory_is_used_when_it_exists
• empty_setting_uses_the_platform_default
• missing_directory_uses_the_platform_default
• file_path_instead_of_a_directory_uses_the_platform_default
• download_dialog_starts_in_the_configured_directory
• download_dialog_without_a_configured_directory_uses_the_platform_default

In crates/flectar-mail-core/src/db/repo/settings.rs, the three existing settings tests are extended, old_blob_gets_field_defaults included, so settings blobs written before this field still load.

rfd::AsyncFileDialog cannot be introspected, so every decision sits in a pure function ahead of it.

Checks

cargo fmt --all -- --check, scripts/check-platform-gates.py, scripts/check-translations.sh and cargo test --workspace --locked pass.

cargo clippy --workspace --all-targets --locked -- -D warnings passes except for a pre-existing clippy::nonminimal_bool hit at crates/flectar-mail-core/src/jmap/client.rs:211, which newer Clippy reports and which I left untouched as unrelated to this change.

Three test failures on my Windows machine are pre-existing and unrelated: files::tests::save_does_not_clobber fails with PermissionDenied and reproduces on an unmodified main, and the two mail_security OpenPGP tests need a working GnuPG.

Why this is a draft

The UI has not been inspected in light and dark themes or at the documented phone and tablet preview sizes yet, as CONTRIBUTING.md requires. tests/text_fit.rs passes, so text fits at desktop font sizes, but that is not the same as the visual review. I will mark this ready once that is done.

Generative tool disclosure

This change was written with Claude Code (Claude Opus 5), as recorded in the commit trailer. No third-party code or assets were copied in, and no dependencies were added.