Move-to-folder drawer opens inside the item's current folder (an empty screen) instead of showing destination folders

Describe the Bug

The move/select-folder drawer initialises to the folder the item is already in:

// @payloadcms/ui/dist/elements/FolderView/Drawers/MoveToFolder/index.js (3.87.0)
const [folderID, setFolderID] = React.useState(props.fromFolderID || null);  // line 48
...
void populateMoveToFolderDrawer(props.fromFolderID);                          // line 79

The drawer only lists subfolders, so for the most common operation — "move this document from folder A to folder B", where A is a leaf folder — the first screen the user sees is the inside of the folder they're trying to leave, which is empty: a "No Results." message and a Create-folder button. No destination is visible. To reach one they must know to click the breadcrumb root first.

In testing with a non-technical user this read as a dead end / error state, and the intended interaction ("navigate up, then pick a destination") was never discovered unprompted. She concluded moving between folders was broken.

Reproduction steps

1. Upload collection with folders: true; create folders A and B; put a document in A.
2. From the list view, click the document's folder pill (or the folder button on its edit view) → the move drawer opens.
3. First screen: inside folder A — "No Results." + Create-folder. Folder B is not visible anywhere.

Expected / Actual

• Expected: a move operation's first screen shows the available destinations (the folder tree from the root, with the current folder indicated).
• Actual: it opens inside the current folder, which for leaf folders is an empty screen with no destinations and no guidance.

Proposed fix

Initialise the drawer at the root folder list:

- const [folderID, setFolderID] = React.useState(props.fromFolderID || null);
+ const [folderID, setFolderID] = React.useState(null);
  ...
- void populateMoveToFolderDrawer(props.fromFolderID);
+ void populateMoveToFolderDrawer(null);

The heading already communicates origin ("Moving X from A"), and the existing confirmation modal guards the move-to-root case. We've run this change in production via a pnpm patch; the flow becomes: open → see all folders → click destination → Select → confirm.

Related polish in the same drawer, happy to split into separate issues if preferred:

• The empty-folder state reuses the generic list strings (general:noResultsFound / noResultsDescription), which read as an error here; a folder-specific string ("No folders inside this one") would allow relabelling without touching every list's empty state.
• Nothing indicates that pressing Select while at the root level means "remove from all folders" — useful, but undiscoverable.

Environment

• Payload: 3.86.0 (found), verified still present in 3.87.0 source
• @payloadcms/db-postgres, @payloadcms/next
• Next.js: 16.2.11
• Node: 22.14.0

Start at @payloadcms/ui/dist/elements/FolderView/Drawers/MoveToFolder/index.js, focusing on the folderID state initialization and populateMoveToFolderDrawer call identified in the issue. Verify the drawer opens at the root, shows destination folders, and still preserves the existing heading and confirmation flow.