fix: reach directly shared files and keep others' files on a failed copy

Fixes from the review of the Files work (1cf9944b..a9a25b94).

- A file shared on its own, or one below a folder its owner took back,
  could not be reached. Once Stalwart 1.0's placeholder folders were
  left out it became a root of "Shared with me", which listed folders
  only, and search opened it on the drive root. 0.16 lists such files
  as roots too. Each owner's files shared on their own are now listed
  on one page under "Shared with me" ("Files from <name>"), where they
  open, preview and download like any other file and nothing can be
  added; two of the same name get a number. Search opens a shared hit
  where it is listed, and links into a shared drive name the node by id
  (`/files?shared=<owner>:<id>`), so a shared folder or page also
  survives a reload. A Files page that is already open takes the link
  from search directly, since Next keeps it mounted when only the query
  changes.
- A copy that fails part-way destroys only the nodes it made, the
  deepest first and without `onDestroyRemoveChildren`, one call per
  level because 0.16 refuses a folder destroyed in the same call as
  its children. It used to destroy the new folder with everything
  below it, so whatever someone put there during a long copy was
  deleted for good. A folder holding such nodes now stays, and the
  error says part of the copy was left in place.
- The document editor opens read-only on 0.16 for a sharee without the
  rename right. 0.16.6 to 0.16.23 refuse any change a sharee makes
  without Modify, so every save of such a document failed with a 500.
  1.0, told apart by its `maxFileNodeDepth`, still asks for
  `mayModifyContent` alone.
- Ctrl+C with only symlinks selected empties the clipboard instead of
  keeping an earlier cut for the next paste.
- A paste reads each account's file tree once, not once per pasted
  item for the listing and 1.0's depth check.
- The Stalwart bundle's README says that on older 0.16 releases and
  the 1.0 pre-releases a failed update also drops the cached copy, and
  the next restart or reload of the Applications downloads it again,
  not only a later `UpdateApps`. The static README says a restart
  applies the CORS setting on the current 1.0 pre-releases, where
  `ReloadSettings` fails with the stock spam-filter rules.

app/api/dev-jmap/[...path]/route.ts

@@ -2282,6 +2282,7 @@ function handleFileNodeSet(args: MethodArgs, callId: string): MethodResult {
   const updated: Record<string, unknown> = {};
   const notUpdated: Record<string, unknown> = {};
   const destroyed: string[] = [];
+  const notDestroyed: Record<string, unknown> = {};
 
   if (args.create) {
     for (const [tempId, props] of Object.entries(args.create as Record<string, Record<string, unknown>>)) {
@@ -2336,9 +2337,17 @@ function handleFileNodeSet(args: MethodArgs, callId: string): MethodResult {
   }
 
   if (Array.isArray(args.destroy)) {
-    // The client always sends onDestroyRemoveChildren: true, so a destroyed
-    // folder takes its subtree with it.
-    const toDestroy = new Set(args.destroy as string[]);
+    const toDestroy = new Set<string>();
+    for (const id of args.destroy as string[]) {
+      // Like Stalwart, a folder that still holds anything goes only with
+      // onDestroyRemoveChildren (the rollback of a failed copy leaves it out).
+      if (!args.onDestroyRemoveChildren && fileNodes.some((n) => n.parentId === id)) {
+        notDestroyed[id] = { type: 'nodeHasChildren', description: 'Cannot delete non-empty folder.' };
+      } else {
+        toDestroy.add(id);
+      }
+    }
+    // A destroyed folder takes its subtree with it.
     let grew = true;
     while (grew) {
       grew = false;
@@ -2366,6 +2375,7 @@ function handleFileNodeSet(args: MethodArgs, callId: string): MethodResult {
     updated,
     notUpdated,
     destroyed,
+    notDestroyed,
   }, callId];
 }