Fix a permanent black line in the note list, and add separators

The drop indicator was a `borderTop` set in the same style object as a `border`
shorthand. Clearing the longhand resets its width and colour to the defaults
while the shorthand's `solid` stays, so a row kept a 2px black line for good —
measured at rest, before any drag. It is now its own element, which also stops
the list twitching as a row grows and shrinks by a pixel.

That element then turned out to be a dead strip of its own: it pushes the row
down as it appears, so the pointer ended up over the line rather than over the
row and releasing there dropped on nothing. The drag handlers moved to the whole
row and the indicator no longer takes pointer events. A strip below the last row
means "put it at the end", which otherwise needs a drop onto the final note.

Separators are lines drawn between notes, optionally named, stored on the
notebook beside its sort mode. They drag like notes do, and their position is
"how many notes come before me", so they hold their place as the notes around
them are renamed or edited. Shown only in the manual order — in "newest first"
the notes would slide past the line on every edit.

"All Notes" and "Starred" no longer offer a hand-made order: they are questions
asked of every notebook, so there is nothing for an arrangement to belong to.

199 unit tests, 190 browser checks across eleven suites.

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

readme.md

@@ -304,7 +304,7 @@ failure distinguished by comparing an error's `.message` to a magic string.
 Failures now carry a typed `SyncError.code`; `.message` still holds the same
 string, so the remaining JavaScript callers are unaffected.
 
-The 186 unit tests concentrate on the same places, and several exist because the
+The 199 unit tests concentrate on the same places, and several exist because the
 bug they cover actually happened:
 
 - a queue entry that fails must stay queued, with an attempt counter
@@ -336,7 +336,7 @@ 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` | 24 | a hand-made order survives a search; a note exported and imported comes back whole |
+| `organise` | 35 | a hand-made order survives a search; separators hold their place; a note exported and imported comes back whole |
 | `offline` | 12 | a cold page load with the network off still opens notes and searches them |
 
 Each suite creates a throwaway account through the admin API and deletes it
@@ -717,7 +717,7 @@ newest-first.
 
 | Mode | Order |
 | --- | --- |
-| `manual` | the user's own arrangement, dragged into place |
+| `manual` | the user's own arrangement, dragged into place — notebooks only |
 | `updated` | most recently changed first *(the default)* |
 | `oldest` | least recently changed first |
 | `created` | most recently created first |
@@ -734,6 +734,18 @@ never re-derived from what is on screen, so two rules hold it up:
 - Dragging is switched off while a search is narrowing the list, and the list
   says so rather than silently ignoring the drag.
 
+"All Notes" and "Starred" are not offered a manual order at all. They are
+questions asked of every notebook at once, so there is nothing for an
+arrangement to belong to and nowhere to keep it.
+
+**Separators** are lines drawn between notes, optionally named, stored on the
+notebook beside the sort mode. 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.
+
 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
 dragging a note would move it to the top of "last changed" and spend a slot of