A chapter with an order of its own

A chapter orders its own notes now, chosen in the same dialog as its name,
mark and colour -- one decision about one thing. The notebook's setting
governs the notebook's own list; a chapter is a place someone made and
filled, so a reference chapter can stay alphabetical while the notebook
around it stays as it was arranged. It starts hand-made, and a chapter put
in one of the other orders loses its lines and its handles exactly as the
notebook does: neither means anything against an order the app is choosing.

A line still would not go under another line, and the comparator was only
half of it. The write was then thrown away by the "did anything change?"
test, which sorted the separators before comparing them -- to ignore the
other chapters' lines riding along in the same field -- and a sorted
comparison cannot see a sequence. Two lines in one gap carry the same
position, so swapping them changes nothing else. It compares this list's own
lines, in order.

An open chapter swelled while rearranging: the strips at the two ends of its
list stood open for the whole of the mode, adding half a finger of empty
space inside every chapter. They are thin now, and only there while
something is actually being carried -- which is also why the suite presses
first and aims afterwards.

Server: sort_mode on chapters, validated against the same five modes as a
notebook's, and set outside the COALESCE so null means the hand-made order
rather than "leave it alone".

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

readme.md

@@ -334,11 +334,15 @@ handlers — a finger generates no `pointerover` on anything it did not press.
 
 **Two lines in the same gap keep the order they were written in.** A separator's
 position counts the rows above it, so two lines with nothing between them carry
-the same number, and only the order they are stored in can tell them apart. The
-comparator used to say "a separator comes first" without asking what the other
-one was — claiming both directions at once for that case. A comparator that
-contradicts itself has no defined result, and a line dragged under another sprang
-back above it every time.
+the same number, and only the order they are stored in can tell them apart. That
+took two fixes for one symptom. The comparator used to say "a separator comes
+first" without asking what the other one was — claiming both directions at once
+for that case, and a comparator that contradicts itself has no defined result.
+And the write was then thrown away: the "did anything change?" test **sorted**
+the separators before comparing them, to ignore the other chapters' lines riding
+along in the same field — and a sorted comparison cannot see a sequence. The move
+was computed correctly, drawn for a frame, and discarded. It compares this list's
+own lines, in order.
 
 **A drop lands the row under the one it was released on, and only ever there.**
 Dropping above a row and dropping below the row before it are the same move
@@ -462,8 +466,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` | 64 | a hand-made order survives a search; separators hold their place; a note exported and imported comes back whole |
-| `chapters` | 51 | a filed note stays filed across a sync; the notebook's separators survive a chapter being opened; handles appear only while rearranging |
+| `organise` | 75 | a hand-made order survives a search; a new note lands on top and a deleted one takes only itself; one line goes under another and stays there |
+| `chapters` | 60 | a filed note stays filed across a sync; a chapter is dragged among its neighbours *and* takes what is dropped in it; its own order is set in its own dialog |
 | `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 |
 | `tables` | 8 | a long table is broken between its rows, with none left lying across the gap, and no page furniture reaches the stored note |
 | `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 |
@@ -1113,15 +1117,22 @@ still reads newest-first — untouched rows all carry position 0 and fall back t
 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.
 
-**Inside a chapter the order is always the user's own.** The mode belongs to the
-notebook and governs the notebook's own list; a chapter is a place someone made
-and filled by hand, and filing a note into one only means something if it stays
-where it was put. So a chapter has no sort menu of its own, its lines always
-show, and its rows can always be dragged — with the *same* switch as the list
-beside it, because two switches for two lists looked at together is one too many.
-The two lists keep out of each other's way 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.
+**A chapter orders its own notes.** The notebook's setting governs the
+notebook's own list; a chapter is a place someone made and filled, so it carries
+a mode of its own — set in the same dialog as its name, mark and colour, because
+they are one decision about one thing. It starts in the hand-made order, which is
+what filing a note into a chapter means: it stays where it was put. A chapter in
+one of the other orders loses its lines and its handles, exactly as the notebook
+does, because neither means anything against an order the app is choosing.
+
+While it *is* in the hand-made order, its rows are dragged with the **same
+switch** as the list beside it — two switches for two lists looked at together is
+one too many. The two lists keep out of each other's way 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 two
+strips at the ends of a chapter's list appear only while something is being
+carried; standing open for the whole of the mode they added half a finger of
+empty space to every open chapter.
 
 **A row leaving is the same problem as a row arriving, in reverse.** Deleting a
 note above a line left the line counting rows that were no longer there, so