**A file** from the phone is the same plugin's `pick_file`, beside
`pick_folder` and `pick_image`: Android's document picker with the caller's
own MIME filter, answered with `{ path, name, size, copied }`. It copies as
little as it can, because an image is small and an audio file is not. A
document already on this phone's storage hands its own path over as it lies
— the DOCUMENT sibling of the tree id the folder picker resolves, plus the
Downloads provider's `raw:` — so picking a 300 MB file costs nothing and
touches no cache. One that has no path (a cloud provider's, a document a
provider only streams) is copied into `cacheDir/picked` under its own
display name, and only as far as the caller's `maxCopyBytes` allows: zero
refuses the copy outright, which is what an audio-sized pick wants, and the
copy counts itself as it goes because a provider's stated size is often
absent and sometimes wrong. Those copies are swept at the start of every
pick — unlike `pick_image`'s, which live in the cache for ever — so a path
from one pick is gone by the next. The display name travels beside the path
because it is load-bearing: `playlist_formats::detect_format` reads the
extension off it and `parse` titles the draft from its stem, so a copy under
an invented name would read every playlist as plain text. The dialog plugin
cannot serve here: `tauri-plugin-dialog` does open the sheet from Rust, but
it answers with a `content://` URI, and `std::fs` cannot take one.