Order the session list by when each agent was turned on

A running session no longer moves: the ones with a process come first,
oldest start first, so starting one appends it to the bottom of that
group and nothing it goes on to do -- beginning a turn, finishing one,
asking a question -- can shift it. Sorting by activity with the
awaiting-answer ones floated to the top is what this replaces; the
status word and its colour already say which session wants something
without the row having to move to say it. Stopped sessions are a group
below, most recently active first.

The order is the server's: `SessionConfig::started` is written each time
a process is started for a session and reported as `started`, so it is
the same on every device and survives a backend restart -- which adopts
processes rather than starting them, and so could not work the times out
for itself. Applied on the phone, because presentation order is a
display decision.

`LiveSession::info` takes the session's config entry rather than a
parameter per field read from it, which is what `AutoResumeView` existed
to bundle; that goes.

Verified on the emulator against the sandbox: three echo sessions kept
their order while the newest-active one was messaged; a stopped and
restarted session moved below one started after it; a stopped session
dropped below every running one; and after a backend restart the
recorded times came back unchanged.

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

PLAN.md

@@ -1121,7 +1121,22 @@ Kotlin + Compose Multiplatform, single `:androidApp` module, same versions as
 dev-updater (Kotlin 2.4.x, CMP 1.11.x, JDK 21).
 
 1. **Session list** — kind icon, title, machine, model, status, last activity.
-   Sessions awaiting an answer sort to the top: the "your turn" inbox.
+   **A session with a process stays where it is, and the order is when each
+   agent was turned on** (2026-09-15, replacing the awaiting-answer inbox
+   sort): the running sessions come first, oldest start first, so one that is
+   started joins the bottom of that group and nothing it goes on to do —
+   beginning a turn, finishing one, asking a question — can move it. A list
+   that reorders itself is one nobody can keep their place in, and the status
+   word and its colour already say which session wants an answer without the
+   row having to move to say it. Stopped sessions are a group below, most
+   recently active first; "turned on" is what the order above is made of and a
+   session with no process has no place in it.
+   The order is the server's (`SessionConfig::started`, reported as
+   `started`), written each time a process is started for the session, so it
+   is the same on every device and survives a backend restart — which adopts
+   processes rather than starting them, and so could not work the times out
+   for itself. Applied on the phone (`sessionsInListOrder`), because
+   presentation order is a display decision.
 2. **Import** — Claude Code sessions the machine already has, selected in
    batches (hold to enter, tap to add), with Delete and Import along the
    bottom. Submitting clears the selection immediately and marks every chosen