The picker names a volume the way the browser does

Two fixes from driving Copy to… and Move to… on the phone.

The dialog was nested inside the conflict-prompt block, so it could only appear when a conflict was already on screen - which is never. Nothing in the unit tests could see that: they test the view model, and the view model was right.

And the picker named internal storage by the platform's own name for it, 0: as the volume row, and in the trail above it (0 / AADst). The roots screen has always shown Internal storage there; the picker now follows the same rule, through a label resource on PickerFolder rather than a second copy of the string logic. A test pins the label on both the row and the crumb.

On the device: copy leaves the source and the selection in place, move empties the source, clears the selection and says Moved 1 item. Recorded in EDGE_CASE_TESTING.md.

docs/ROADMAP.md

@@ -86,8 +86,9 @@ release should not go out without.
    picked folder without leaving the current one. The selection survives a copy so a second destination is
    two taps; a move clears it. Conflicts ask the same question as a paste, naming the picked folder. Seven
    tests cover the verbs, the picker's walk, folders-only listing, the conflict target, cancellation, and
-   the selection rule. **Not done**: the "copied to X — Show" message with a jump to the destination; the
-   copy reports itself the way a paste does.
+   the selection rule. Driven on the phone for both verbs (see `EDGE_CASE_TESTING.md`), which is what caught
+   the picker naming internal storage by its raw name `0`. **Not done**: the "copied to X — Show" message
+   with a jump to the destination; the copy reports itself the way a paste does.
 5. **A CI run of the benchmarks on an emulator** — removes the phone from the loop and reports
    `frameDurationCpuMs`, which this device cannot.