Chapters: folders inside a notebook

A note is in exactly one chapter, or in none — which means the notebook
itself. Chapters sit above the loose notes; tapping one opens its own
list and the menu button becomes the way back out, which on a phone is
the only way, since the list fills the screen.

A chapter is not a wastebasket. Removing one never removes what it held:
the notes come back to the notebook, where they can be seen and filed
again. That is ON DELETE SET NULL, and it is also written out in the
delete route, because it is the promise the whole thing rests on and
should be visible where it happens rather than inferred from a schema.
The dialog says so too, with the number of notes affected, and the suite
removes a chapter holding three notes and asks the server for all three.

Three rules keep the two levels honest. A note filed into a chapter
leaves the notebook's own list, or filing it would appear to do nothing.
A chapter belongs to its notebook, so the server refuses to file a note
into a chapter of a book it is not in, and moving a note to another
notebook clears its chapter. And separators belong to the list they were
drawn in: a separator's order counts the notes before it, which means
nothing across lists.

Two bugs found while building it, both a day old and both affecting the
desktop rather than the phone they were written for:

- A submenu was clipped away. The context menu had been given
  `overflow-y: auto`, which cuts off anything flying out sideways — so
  the notebooks under "Move to..." were invisible and every click on them
  landed on the note list behind. The side was inverted too:
  `right: 100%` places a panel on the left.
- A separator was a one-pixel hairline in the border colour with faint
  grey text on near-black. Present, and on a phone effectively invisible.

And one test that never measured what it claimed. It asked whether a
dragged note had become "the most recently changed" by reading the order
on screen — but three notes made seconds apart share an `updated_at`
second, so that order is a tie broken arbitrarily. It passed on luck for
weeks and fell over on a run a fraction faster. It now compares the
timestamps themselves, before and after the drag.

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

e2e/organise.mjs

@@ -134,13 +134,33 @@ try {
   );
 
   /* Reordering must not look like editing: a dragged note keeps its place in
-     "last changed", or the two orders would fight each other. */
-  await sortBy("updated");
+     "last changed", or the two orders would fight each other.
+
+     Asked of the timestamps rather than of the order on screen. Three notes made
+     seconds apart routinely share an `updated_at` second — the column has that
+     resolution — and then "which is newest" is a tie broken arbitrarily. The
+     check passed on luck for weeks and started failing on a run that was a
+     fraction faster. */
+  const stamps = async () =>
+    Object.fromEntries((await api(p, "GET", "/notes")).body.map((n) => [n.title, n.updated_at]));
+
+  await sortBy("manual");
+  await p.waitForTimeout(600);
+  const beforeStamps = await stamps();
+  const order = await titles();
+  await drag(rows.nth(2), rows.nth(0));
+  const afterStamps = await stamps();
   check(
-    (await titles())[0] === "Gamma",
-    "a dragged note did not become the most recently changed one",
-    (await titles()).join(", ")
+    Object.keys(beforeStamps).every((t) => beforeStamps[t] === afterStamps[t]),
+    "dragging a note does not mark it as changed",
+    `${JSON.stringify(beforeStamps)} → ${JSON.stringify(afterStamps)}`
   );
+  check(
+    (await titles()).join(",") !== order.join(","),
+    "though it did move",
+    `${order.join(",")} → ${(await titles()).join(",")}`
+  );
+
   await sortBy("manual");
   await p.waitForTimeout(800);
 
@@ -160,6 +180,8 @@ try {
   );
 
   /* ── separators ── */
+  // The arrangement as it stands now: rows have been dragged since `arranged`.
+  const beforeSeparator = await titles();
   await p.locator("[data-add-separator]").click();
   await p.waitForTimeout(1800);
   check((await p.locator("[data-separator]").count()) === 1, "a separator can be added");
@@ -194,9 +216,9 @@ try {
 
   const withSeparator = await titles();
   check(
-    withSeparator.join(",") === arranged.join(","),
+    withSeparator.join(",") === beforeSeparator.join(","),
     "and adding one did not disturb the arrangement",
-    `${arranged.join(",")} vs ${withSeparator.join(",")}`
+    `${beforeSeparator.join(",")} vs ${withSeparator.join(",")}`
   );
 
   // Separators only mean something in a hand-made order; in "newest first" the