[springmin]

Compose attachments, account-backup export/import and database-snapshot
export still opened desktop file dialogs (rfd) directly, so on mobile they
reported "no picker" even though the host provides a DocumentProvider. This
routes all three through the provider.

What changes

• The document entry points are no longer hidden on mobile:
  document_apis_supported is true on every host now that all of them provide
  a DocumentProvider, so the compose attach button and the Storage
  backup/snapshot cards show up on phones and tablets.
• DocumentProvider::import_many() imports several documents for one user
  action. The default imports one document per request, so a single-document
  picker (Android, iOS, OpenHarmony) never opens twice for one tap; the desktop
  provider overrides it with one multi-select dialog. The composer keeps the returned documents alive until
  Core has staged the attachments, which is how the trait already describes
  owned import copies.
• Compose attachments use import_many(); the duplicate, size and 25 MB total
  checks and their notices are unchanged.
• Account-backup export writes the JSON to an app-private staging file and
  hands it to export(); import awaits import() and then runs the existing
  verified import logic on the UI-thread executor, so the state updates keep
  their current shape.
• Database-snapshot export still produces Core's verified snapshot, then
  archives it as one zip (hosts export files, not folders) and hands it to
  export(). Staging is created outside the data/cache roots Core requires for
  snapshots, which also covers hosts whose TMPDIR is the app cache. The
  archiver skips symlinks and declares no path outside the snapshot directory.
• Desktop behavior is unchanged: same dialogs, same file names, same 1 MB
  backup limit. Nothing about the JSON formats or the credential exclusion
  changes.

Validation

• cargo fmt --all -- --check: clean.
• python3 scripts/check-platform-gates.py: passes.
• cargo clippy for the shared application with the mobile configuration
  (OpenHarmony target): clean.
• New unit tests cover the default import_many (cancellation ends the loop,
  the limit is honored, and dropped imports release their copies).
• OpenHarmony (HarmonyOS 7.0.0.111, API 26): the port builds and runs with
  these paths wired to the ArkTS pickers; the interactive flows are part of the
  port's manual test matrix (tracked in OpenHarmony (HarmonyOS) platform support — interest in a port contribution? #77).

Contribution and licensing

• I have the right to submit this work.
• Third-party dependencies/assets: zip 9.0.4 (MIT, already in the
  dependency graph through flectar-mail-core; the root crate now declares it
  directly with default features off and uses Stored compression only) for the
  snapshot archive. No new asset.
• Disclosed generative-tool assistance: the change was developed with an AI
  coding agent (LLM); I reviewed every line, ran the checks above, and tested
  the behavior as described.
• No credentials, private mailbox data, signing material, or unnecessary
  personal information included.

[springmin]

Note on the RustSec job: it fails on RUSTSEC-2026-0370 / RUSTSEC-2026-0372
(zvariant / zvariant_derive 5.15.0 unmaintained), published 2026-10-16.
This pull request only adds the already-present zip dependency edge to the
lockfile and changes no package versions, so the next scan of main reports
the same advisories. Every other check (format, clippy, tests, all platform
lints) passes on the current head.

[springmin]

FYI for the mobile hosts (not a request to change anything here): on
OpenHarmony the system document picker covers the application window and the
XComponent surface hide callback does not fire for a covered window, so
running the provider future on the runtime leaves the presentation thread
submitting frames into a buffer queue the compositor is not consuming. The
compose window then stops responding after the picker returns (reproduced on
HarmonyOS 7.0.0.111 with the visibility gate active).

The reference OpenHarmony port blocked the calling thread while the picker was
up instead; that is the policy the platform keeps in #85. Desktop targets are
unaffected — the native dialog needs the event loop, which the current design
correctly keeps alive.

[iamdarkle]

Thanks for the heads-up on the OpenHarmony picker, and for this contribution, routing these flows through the document provider is a solid step for the mobile hosts. I added follow-up commits that run the requests on the Tokio runtime (backup export panicked on every platform, and the mobile pickers panicked on their timers outside it), restore the desktop dialog titles and filters, keep the folder picker for desktop snapshots, guard against repeated clicks, and stop mobile snapshot export early when the archive would exceed the 512 MiB transfer limit. CI is green, so this is ready to merge.

For #85, every picker and export now goes through documents::run_request, so after rebasing, the OpenHarmony blocking policy only needs to change that one function. Snapshot export stages and zips on the runtime first, so only the picker step would block. Also note that the desktop branch of with_document_future in #85 awaits the provider future on the UI thread outside the runtime, so desktop backup export panics there because save_cached_file uses tokio::fs. Rebasing onto run_request removes that path.