Record the post-1.0 queue, and close the competitor's post-paste pair as superseded

ROADMAP now carries the queue in the order it should be done - baseline profile, thumbnail hardening, the 5k/20k scaling numbers, then Copy to / Move to (M16, specified with acceptance criteria), then a CI emulator run - and states why nothing there is scheduled yet.

The interesting part is the copy decision. The competitor's Copy again and Return to source folder are not deferred, they are superseded: both exist because their flow makes you leave the source folder to paste. Copy to / Move to removes that constraint at the source, so the selection is still there for the next destination and there is no back-to-source to offer. The spec records that the engine half already exists - paste() calls planTransfer(paths, target, policy) with the current folder as target and the engine is target-agnostic, so FileOpService and the conflict prompt work from anywhere - and that the missing piece is a folder picker. COMPETITIVE_ANALYSIS points at the same decision in both places it mentioned the pair, so the two documents cannot drift apart.

docs/COMPETITIVE_ANALYSIS.md

@@ -309,7 +309,7 @@ requested feature in the market leader, and the permission line is a claim it ca
 | Duplicate finder | **No** | Explicitly requested, with an offer to pay. Pure local computation over a listing we can already do |
 | Batch rename, including continuing an existing numbering sequence | **No** | **Closed in M14.** Several files are renamed to one name with a number after each, and the numbering continues the folder's own series, so the "Ice (3), Ice (4)" wish from the top complainant is what the dialog now defaults to |
 | Bookmarks | **No** | **Closed in M15.** A star on any folder puts it in **Favourites** on the home screen, above the libraries; a folder that has gone is kept and marked rather than dropped |
-| "Copy again" / "Return to source folder" after a paste | **No** | Shipped in their 3.6.8 and cheap for us — the post-paste moment is when a user most needs a way back |
+| "Copy again" / "Return to source folder" after a paste | **No** | **Closed as superseded.** Both exist because their flow makes you leave the source folder to paste; [ROADMAP](ROADMAP.md) specifies **Copy to… / Move to… (M16)** instead, which never leaves the source — so the selection is still there for the next destination and there is no "back to source" to offer |
 | New-file dot after an operation | **No** | Their 3.6.5. Cheap, and it answers "what did that 4 GB copy just do?" |
 | Date-format setting | **No** | We deliberately leave the timestamp pattern unlocalised (README); a *user setting* is a different thing |
 | Music-player engine switch, video gesture toggle | **No** | Deep settings; low priority for a first release |
@@ -355,9 +355,10 @@ In the ROADMAP's own vocabulary (💡 = candidate, proposed, not scheduled; ✅
 2. ✅ **Duplicate finder** — shipped as **M12**. Asked for by name, by a user offering to pay.
 3. ✅ **Batch rename with sequence continuation** — shipped as **M14**, including the "continue from
    Ice (2)" case that the top complainant names.
-4. ✅ **Bookmarks** — shipped as **M15**. 💡 **"Return to source folder" and "Copy again"** after a
-   paste remain: cheap, local, and the post-paste moment is the one the competitor's changelog
-   calls out.
+4. ✅ **Bookmarks** — shipped as **M15**. ~~💡 "Return to source folder" and "Copy again" after a
+   paste remain~~ — **closed as superseded**: both are workarounds for having to leave the source folder
+   to paste, and **Copy to… / Move to…** ([ROADMAP](ROADMAP.md), M16) removes that constraint, so the
+   selection is still there for the next destination and there is no "back to source" to offer.
 5. 💡 **Highlight files changed by an operation.** Their 3.6.5; answers an obvious question.
 6. **Thumbnail hardening before the next release**: register an explicit Coil `ImageLoader` with a
    decided cache policy and a placeholder, and record a large-folder device pass in

docs/ROADMAP.md

@@ -1,7 +1,8 @@
 # Roadmap
 
 File Manager is built against a fixed milestone plan (**M0–M15**). This file is the
-single source of truth for what is done and what remains.
+single source of truth for what is done and what remains. M16 is specified below but **not scheduled** —
+it is the first item of the post-1.0 queue that is a feature rather than a safeguard.
 
 Legend: ✅ done · 🚧 in progress · ⏳ not started · 💡 candidate (proposed, not scheduled)
 
@@ -52,6 +53,56 @@ Legend: ✅ done · 🚧 in progress · ⏳ not started · 💡 candidate (propo
 A survey of the market leader (its features, and what its users praise and complain about) is in
 [COMPETITIVE_ANALYSIS](COMPETITIVE_ANALYSIS.md). Its gaps that cost **no** new permission are
 listed there as 💡 candidates. **Four of them have since been shipped: category libraries (M11), the
-duplicate finder (M12), batch rename with sequence continuation (M14) and favourites (M15)**. What is
-left — the post-paste "copy again" / "return to source folder" — is a proposal, not scheduled work,
-and taking it on is a roadmap decision rather than a side effect of reading that document.
+duplicate finder (M12), batch rename with sequence continuation (M14) and favourites (M15)**.
+
+The last one standing there — the post-paste **"copy again"** and **"return to source folder"** — is
+**closed as superseded**, not deferred: both exist only because that app's flow makes you leave the
+source folder to paste. `Copy to…` / `Move to…` (in the queue below) removes that constraint, and with it
+both features: you never leave the source, so the selection is still there for the next destination, and
+there is no "back to source" to offer. Keeping them would be building a workaround for a limitation we
+would no longer have.
+
+## The queue after 1.0
+
+Ordered by what it protects, not by what is fun. Nothing here is scheduled; the first two are what a
+release should not go out without.
+
+1. **Baseline profile** — generate one, commit it, re-run `coldStart`, and publish the delta next to the
+   532 ms figure in [PERFORMANCE](PERFORMANCE.md). This is the only item that makes the app measurably
+   faster for everyone; it needs the `androidx.baselineprofile` plugin, which is not in the offline
+   Gradle cache and so has to be fetched first.
+2. **Thumbnail hardening before the next release** — an explicit Coil `ImageLoader` with a decided cache
+   policy and a placeholder, plus a large-folder device pass recorded in
+   [EDGE_CASE_TESTING](EDGE_CASE_TESTING.md). The only item here that touches code changed late in 1.0.
+3. **The scaling numbers** — `./tools/benchmark-fixture.sh --count 20000` and the existing benchmarks:
+   answers whether a full SD card is a performance problem before a user with one finds out.
+4. **Copy to… / Move to… (M16)** — the comfort feature, specified below.
+5. **A CI run of the benchmarks on an emulator** — removes the phone from the loop and reports
+   `frameDurationCpuMs`, which this device cannot.
+
+### M16 — Copy to… / Move to…
+
+**What**: from a selection, choose a destination folder and start the copy (or move) immediately, without
+leaving the folder you are in.
+
+**Why this shape**: `BrowserViewModel.paste()` already calls `planTransfer(paths, target, policy)` with the
+current folder as `target`; the engine is target-agnostic, so the operation half needs no new machinery —
+`FileOpService` and the conflict prompt work regardless of what is on screen. What is missing is a
+destination picker.
+
+**Acceptance criteria**
+
+- Selecting files and choosing *Copy to…* opens a folder picker: folders only, one level at a time, with
+  Up and breadcrumbs, every root the app can see (internal and SD card), and the granted tree in SAF mode.
+- Confirming copies into the chosen folder and **leaves the user where they were**, with the selection
+  still intact — so a second destination is two taps. `Move to…` is the same picker with `cut = true`.
+- A name conflict asks the same question as a paste does, with the picked folder named in it, and resolve
+  applies to that folder.
+- Progress belongs to the existing operation notification, not to the screen the user is on.
+- After a copy, a message names the destination and offers to show it. After a move the selection is
+  cleared and the listing refreshed, because the rows are gone.
+- Tests: plan/enqueue with an explicit target; the conflict prompt carrying the picked folder; selection
+  survives a copy and is cleared by a move; the picker lists folders only.
+
+**Not in scope**: drag and drop, a two-pane phone layout, remembering recent destinations.
+