feat: order the session list by attention, not by when you created it

[saucam]

Fixes the "session panel order seems mostly random" report.

Why it looked random

web/src/state/sessions.ts sorted by createdAt — under a comment reading "Sorted list — most recent activity first." The intent was always recency; the code delivered creation order. A session made last week but driven all morning sat at the bottom.

It could not be fixed client-side. The daemon has always tracked #lastActivityAt — it already orders the resumed session list by it — but never put it on the wire; SessionInfo carried only createdAt. There is a lastActivityAt in web/src/state/messages.ts, but it's derived from messages this client received, so it's 0 for every session you haven't opened. That's a trap for the obvious fix, so it's worth knowing it's there.

The design

Adds lastActivityAt to SessionInfo (optional — clients fall back to createdAt, so an older daemon doesn't sink every session to epoch 0) and bands the list:

NEEDS YOU   waiting_approval, error
WORKING     thinking, tool_running
IDLE        everything else, most recently active first

Bands rather than one flat multi-key sort, for three reasons:

1. It's already this project's answer. conductor-frontends-design.md §4 locks a state-grouped list as the fleet view's primary, partly because it renders identically in Solid and ratatui. A second ordering vocabulary in the same client would be a bug in itself.
2. It absorbs thrash. thinking and tool_running alternate several times a second; both are WORKING, so nothing moves. A flat sort keyed on status would jitter continuously.
3. It makes movement legible. A row crossing under a NEEDS YOU header reads as a state change; the same row silently rising in a flat list reads as a glitch.

error bands as NEEDS YOU, not IDLE — a failed session is the other thing wanting a human, and burying it under idle sessions is how a failure goes unnoticed for an hour.

The two details that matter more than the sort

• A fleet bands and dates as ONE unit — most urgent state, most recent activity anywhere in it. An orchestrator sits idle while its children work, so banding on the lead alone would file a fleet whose child is blocked on an approval under IDLE: exactly the case NEEDS YOU exists to surface.
• Ordering is held while the pointer is over the list, applied on leave. A row that moves between aiming and clicking opens the wrong session. Membership is deliberately not held — a destroyed session must disappear, since leaving it clickable trades a misclick for a worse one.

Ordering stays client-side: the daemon owns state and exposes the field, each client decides how to render it. That's what lets the TUI and mobile band differently later.

Companion

highflame-ai/codeoid-ui — mirrors the field. The TUI doesn't order by it yet; that lands with P5.1 so web and TUI adopt one vocabulary rather than drifting.

Verification

• 13 new tests over the pure ordering functions (web/src/lib/session-order.test.ts), covering band assignment, fleet roll-up, the createdAt fallback, an unparseable timestamp, determinism for same-millisecond sessions, and hold-under-pointer including the membership carve-out
• daemon 2313 pass, 0 fail · web 422 pass · Rust 7 suites
• lint / typecheck / cargo fmt / clippy clean; web build clean

Follow-ups I did not fold in

Pinning (a manual override for long-lived sessions) and a collapsed "N idle" roll-up at fleet scale are both natural next steps, but they're UI features rather than fixes to the reported problem.