Let the reader put the session list in its own order

Nothing sorts the sessions tab any more. The order is the server's
`sessions` list, which is the reader's arrangement: holding a row puts the
screen in selection mode -- the same gesture and the same bottom bar as the
import tab -- and each card grows a burger handle at its right edge that
drags the row to a new place, with a tick of haptic feedback for each one it
passes.

The two attempts this replaces, sorting by activity and then by when each
agent was turned on, were both looking for an order a session could not move
itself out of; no rule computed from what a session is doing can be one.
`POST /sessions/order` rewrites the config's order, so it is the same on
every device and survives a backend restart, and `SessionConfig::started`
goes with the sort that needed it.

Rearranging is independent of the selection: the handle moves the row it is
on, picked out or not. The click moved off the card and onto its contents so
that a press landing on the handle cannot also select the row it is about to
move. Selection's one action is Delete, which now takes the whole set.

Two traps in `Reorder.kt`, both measured on the emulator and written down in
`this-machine-android`: a crossing is decided from how far the finger has
travelled, because a lazy list animates an item into its new place and its
`offset` reports the old one for several frames; and the viewport is pinned
with `requestScrollToItem` around each move, because a lazy list keeps its
place by the key of the top item and would otherwise follow the row being
dragged.

Verified on the emulator against the sandbox: the order survives an app
restart and a backend read-back, a two-row drag moves exactly two rows, a
drag to the bottom edge scrolls the list and lands the row last, pressing the
handle without moving changes nothing, and deleting two selected sessions
leaves the rest in place.

app/androidApp/src/main/kotlin/com/example/aiapp/NerdIcons.kt

@@ -28,7 +28,7 @@ import androidx.compose.ui.unit.sp
  * This replaced a hand-drawn canvas gear, whose doc comment argued against icon fonts on the
  * grounds that a system font may not have the glyph. That objection is about *relying* on a system
  * font, and it is exactly right: the answer is not to avoid glyphs but to ship them. The font here
- * is `app/build-icon-font.sh`'s output -- seventeen glyphs, 2.8 KB, subset out of the 3 MB symbols
+ * is `app/build-icon-font.sh`'s output -- eighteen glyphs, 2.9 KB, subset out of the 3 MB symbols
  * font and committed. Adding one means adding its codepoint in *both* places; a codepoint here that
  * the script did not subset is a glyph that silently isn't there.
  *
@@ -136,6 +136,16 @@ val EDIT_GLYPH = glyph(0xF03EB)
  */
 val SAVE_GLYPH = glyph(0xF0193)
 
+/**
+ * `md-menu` -- the burger: three stacked rules, drawn as the handle a row is dragged by.
+ *
+ * The mark for "take hold of this and move it" rather than for a menu, which is what it means on a
+ * row that has one: three rules look like the rows of a list, and the only thing here that draws
+ * them is a list being rearranged. Nothing else in this app opens a menu from a burger, so the two
+ * senses cannot be confused.
+ */
+val DRAG_GLYPH = glyph(0xF035C)
+
 /**
  * The size an icon draws at beside a line of text.
  *
@@ -165,7 +175,7 @@ private val GLYPH_EXTENT = GLYPH_SIZE.value.dp
  * own corners and beside a title it arrived at the first letter. And it is taller than any header's
  * text, which is what lets the button fill a header row rather than sit in the middle of one.
  */
-private val GLYPH_BUTTON_SIZE = 48.dp
+val GLYPH_BUTTON_SIZE = 48.dp
 
 /**
  * The ring itself, for putting something that is *not* a glyph button next to one -- a title beside