A notebook opens in its own order

The hand-made order is where a notebook's own arrangement lives:
separators show, rows can be put where they belong, nothing slides about
by itself. Starting in "last changed" made both of those look broken
until the sort menu was found — pressing "+ Separator" there drew a line
the order cannot display, so the button appeared dead. A notebook nobody
has arranged still reads newest-first, because untouched rows all carry
position 0, so nothing is lost by starting there. The views keep "last
changed": they are questions asked of every notebook at once and have
nowhere to keep an arrangement. The button that draws a line is now only
offered in the order that can show one.

Removing a chapter left you stuck in the confirmation. Every destructive
action goes through one helper that takes the question down again; this
one set the dialog directly and bypassed it, so the chapter was removed
and the prompt stayed over the app. Closing now happens where the dialog
is rendered, so it happens whoever asked and however they asked.

The suites did not catch that, and the reason is worth keeping: they
read the list straight through the overlay, which is in the DOM the
whole time, and passed while the screen was in fact stuck. Both now
assert the question is gone afterwards.

The separator is no wider than its name. It sat in a fixed 132px slot —
chosen so the row would not jump when renaming began — with a short name
floating in a gap it did not fill.

Thirteen suites green: 345 browser checks, 241 unit tests.

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

readme.md

@@ -439,8 +439,8 @@ docker compose -f docker-compose.dev.yml up -d --build   # must be running
 | `attachments-lifecycle` | 10 | a picture is kept while any version shows it, and freed once none does |
 | `conflict` | 10 | a late write wins but the state it buries survives as a version |
 | `export` | 21 | the downloaded bytes are real Markdown, ZIP and PNG, unpacked and read back |
-| `organise` | 53 | a hand-made order survives a search; separators hold their place; a note exported and imported comes back whole |
-| `chapters` | 34 | a filed note stays filed across a sync; the notebook's separators survive a chapter being opened; handles appear only while rearranging |
+| `organise` | 58 | a hand-made order survives a search; separators hold their place; a note exported and imported comes back whole |
+| `chapters` | 36 | a filed note stays filed across a sync; the notebook's separators survive a chapter being opened; handles appear only while rearranging |
 | `offline` | 17 | a cold page load with the network off still opens notes and searches them — and a note made, written and drawn on offline arrives whole once there is a connection |
 | `sync` | 7 | a PDF written on one device — document, drawing and pinned notes — reaches a second one, which can find it by its contents without opening it |
 
@@ -1059,10 +1059,22 @@ finding one sorted differently on the phone than on the desktop is its own small
 annoyance. A reference book can stay alphabetical while a journal stays
 newest-first.
 
+**A notebook starts in the hand-made order.** That is where a notebook's own
+arrangement lives: separators show, rows wear their handles once rearranging is
+switched on, and nothing slides about by itself. A notebook nobody has arranged
+still reads newest-first — untouched rows all carry position 0 and fall back to
+it — so nothing is lost by starting there, while starting in "last changed" made
+both separators and dragging look broken until the sort menu was found.
+
+The views are different: "All Notes", "Starred" and the bin are questions asked
+of every notebook at once, so there is nothing for an arrangement to belong to
+and nowhere to keep it. They start in "last changed" and are not offered the
+hand-made order at all.
+
 | Mode | Order |
 | --- | --- |
-| `manual` | the user's own arrangement, dragged into place — notebooks only |
-| `updated` | most recently changed first *(the default)* |
+| `manual` | the user's own arrangement, dragged into place — notebooks only, *and what a notebook starts in* |
+| `updated` | most recently changed first *(the default for the views: All Notes, Starred, the bin)* |
 | `oldest` | least recently changed first |
 | `created` | most recently created first |
 | `title` | A–Z, case- and umlaut-aware, with numbers read as numbers |
@@ -1090,9 +1102,15 @@ edit, and the × for removal sat a few pixels from that same target. Removal ask
 first, and says the notes are not affected. They move by dragging like a note does — a
 divider that cannot move with what it divides is worse than none — and their
 position is recorded as "how many notes come before me", so they stay put as the
-notes around them are renamed, edited or opened. They are shown only in the
-manual order: in "newest first" the notes would slide past the line on every
-edit.
+notes around them are renamed, edited or opened.
+
+One press draws the line; it is named afterwards from its own menu, the same way
+it is renamed. A line reads perfectly well unnamed, so nothing is asked first.
+
+They are shown only in the manual order: in "newest first" the notes would slide
+past the line on every edit — and **the button that draws one is only there in
+that order too**. Standing in the others it could do nothing at all when pressed,
+which reads exactly like a button that is broken.
 
 Reordering also has its own route, `POST /api/notes/reorder`. Going through
 `PUT /api/notes/:id` would bump `updated_at` and snapshot a version — so