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>

e2e/organise.mjs

@@ -344,6 +344,25 @@ try {
     (await layout()).join(" | ")
   );
 
+  /* ── and taking one away is the same promise, in reverse ──
+   * A line's position counts the rows above it, so deleting a note above one
+   * left the line counting rows that were no longer there: everything under it
+   * appeared to jump up past the line, which is what made deleting feel as
+   * though it scrambled the notebook. */
+  const beforeDelete = await layout();
+  await p.locator("[data-note-row]").first().click({ button: "right", force: true });
+  await p.waitForTimeout(600);
+  await p.locator("[data-context-menu]").getByText("Move to Trash", { exact: true }).click();
+  await p.waitForTimeout(700);
+  await p.locator("[data-confirm-dialog]").getByRole("button", { name: "Move to Trash", exact: true }).click();
+  await p.waitForTimeout(2500);
+  const arrangedRows = await layout();
+  check(
+    arrangedRows.join(" | ") === beforeDelete.slice(1).join(" | "),
+    "deleting a note takes out only that note — the lines keep the rows they were drawn above",
+    `${beforeDelete.join(" | ")} → ${arrangedRows.join(" | ")}`
+  );
+
   /* ── the choices reach the server, and the screen ──
    * A notebook divided into three parts is easier to read at a glance when the
    * lines differ; grey-on-grey they all look like the same line repeated. */
@@ -390,7 +409,7 @@ try {
     "and the question is gone with it, not left standing over the app"
   );
   check(
-    (await titles()).join(",") === afterNew.filter((row) => !row.startsWith("──")).join(","),
+    (await titles()).join(",") === arrangedRows.filter((row) => !row.startsWith("──")).join(","),
     "with every note still there",
     (await titles()).join(", ")
   );