A chapter is a list too, and deleting stops moving things

Deleting a note moved everything else. A row leaving is the same problem as
a row arriving, in reverse: a line's position counts the rows above it, so a
note deleted above a line left the line counting rows that were no longer
there, and everything under it appeared to jump up past it. withoutRow
renumbers the list a row leaves, and every place one leaves says so -- the
bin, a move, a chapter being removed. Arrivals land at the top: an old
position belongs to an arrangement that has moved on.

A line could not be dragged under another line. Two lines in the same gap
carry the same position, and the comparator claimed "a separator comes
first" without asking what the other one was -- both directions at once for
that case. A comparator that contradicts itself has no defined result, so
the sort returned them in whichever order it happened to walk.

A chapter is always in the user's own order and can be arranged like any
other list: its notes wear handles under the same switch as the list beside
them and are dragged among themselves, strips at both ends included. The two
lists keep apart by scope -- a chapter unfolded under its row holds rows
inside a row of the notebook's list, so the nearest row above the pointer
cannot say which list a drag belongs to. The sort menu is gone inside a
chapter: the mode belongs to the notebook, and a menu there would offer a
choice that cannot be honoured.

The chapters suite no longer assumes the first chapter row is the one that
matters. A chapter is a row in the arrangement and can be anywhere in it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

frontend/src/features/notes/noteSort.ts

@@ -161,11 +161,20 @@ export function mergeEntries(
     separator,
   }));
 
-  return [...rowEntries, ...separatorEntries].sort(
+  return [...rowEntries, ...separatorEntries].sort((a, b) => {
+    if (a.order !== b.order) return a.order - b.order;
+    /* Two lines in the same gap keep the order they were written in.
+     *
+     * This used to say "a separator comes first" without asking what the other
+     * one was — so for two separators it claimed *both* directions at once. A
+     * comparator that contradicts itself has no defined result, and the sort
+     * returned them in whichever order it happened to walk: a line dragged under
+     * another sprang back above it, every time. */
+    if (a.kind === "separator" && b.kind === "separator") return 0;
     // A separator sitting at the same position as a row comes first, so
     // "a line above this one" lands where it was asked for.
-    (a, b) => a.order - b.order || (a.kind === "separator" ? -1 : 1)
-  );
+    return a.kind === "separator" ? -1 : 1;
+  });
 }
 
 /** The result of a drag: what to write back for each kind of row. */
@@ -256,22 +265,51 @@ export function placeOnTop(
   notes: NoteMeta[],
   separators: Separator[],
   chapters: Chapter[],
-  id: string
+  ids: string | string[]
 ): Arrangement | null {
-  const note = notes.find((n) => n.id === id);
-  if (!note) return null;
-  /* Built from the list *without* the new note, then the note put in front.
+  const wanted = Array.isArray(ids) ? ids : [ids];
+  const arriving = wanted
+    .map((id) => notes.find((n) => n.id === id))
+    .filter((n): n is NoteMeta => !!n);
+  if (arriving.length === 0) return null;
+  /* Built from the list *without* the new notes, then those put in front.
    *
-   * Merging it in first would be measuring the room after the furniture moved:
-   * the new row already counts as a row, so every line reads as sitting one
-   * place further down than it was drawn, and renumbering would write that
+   * Merging them in first would be measuring the room after the furniture
+   * moved: a new row already counts as a row, so every line reads as sitting
+   * one place further down than it was drawn, and renumbering would write that
    * misreading back as the truth. */
+  const held = new Set(arriving.map((n) => n.id));
   const entries = mergeEntries(
-    notes.filter((n) => n.id !== id),
+    notes.filter((n) => !held.has(n.id)),
     separators,
     chapters
   );
-  entries.unshift({ kind: "note", id, order: 0, note });
+  entries.unshift(...arriving.map((note) => ({ kind: "note" as const, id: note.id, order: 0, note })));
+  return toArrangement(entries);
+}
+
+/**
+ * The whole list renumbered with one row taken out of it.
+ *
+ * For a note being thrown away or moved elsewhere. A row leaving is the same
+ * problem as a row arriving, in reverse: a separator's position counts the rows
+ * above it, so a note deleted above a line left that line one row too *low*, and
+ * everything below the line appeared to jump up past it. Nothing here moves
+ * except what is leaving.
+ *
+ * `notes` must still contain the row — it is the list as it is drawn, which is
+ * what the lines were counted against.
+ */
+export function withoutRow(
+  notes: NoteMeta[],
+  separators: Separator[],
+  chapters: Chapter[],
+  id: string
+): Arrangement | null {
+  const entries = mergeEntries(notes, separators, chapters);
+  const at = entries.findIndex((e) => e.id === id);
+  if (at < 0) return null;
+  entries.splice(at, 1);
   return toArrangement(entries);
 }