Enhancement: expose last-activity timestamp on sessions (and allow sorting by it)

[geertvanzoest]

🚀 Enhancement Request

Is your enhancement request related to a problem? Please describe.

A session carries no indication of when it was last active, so any client that wants to surface "what has been happening recently" cannot do so.

Concretely: I maintain a browser UI for self-hosted Honcho servers. Its overview page listed the five most recent sessions. Because created_at is the only timestamp available, a workspace where messages had been streaming into an existing session for hours still showed 9h ago at the top — the moment a session was created had not changed. It read as "the deriver has stalled", while the queue was in fact at 359/360 completed with the newest message six minutes old. The sessions ranked highest were the emptiest ones (0 and 1 message); the busiest session was nowhere in the list.

Working around it client-side is not viable. On Honcho 3.0.11:

• The session object exposes ['configuration', 'created_at', 'id', 'is_active', 'metadata', 'workspace_id'] — no updated_at, no last_message_at.
• POST /v3/workspaces/{workspace_id}/sessions/list accepts only reverse, page and size — no sort key.
• POST /v3/workspaces/{workspace_id}/search is semantic (a query is required, results are ranked by relevance), so it cannot stand in for a chronological feed.

That leaves fetching the newest message per session. In the workspace above that is 1042 requests to render a five-row card.

Describe the solution you'd like

Two parts, the first of which is the one that matters:

1. A last-activity timestamp on the session object — last_message_at (or updated_at, if it is defined as "last message appended" rather than "row touched"). Servers already know this; it is the created_at of the newest message in the session.
2. A sort key on sessions/list — something like sort_by: created_at | last_message_at alongside the existing reverse. Without it, clients would still have to page through every session to order by the new field.

Part 1 alone is already useful: a client can then show "last active X ago" per row honestly, even if the ordering stays creation-based.

Describe alternatives you've considered

• N+1 over sessions (one messages/list per session to read its newest timestamp). Correct but unusable at 1042 sessions, and it scales with workspace size rather than with what is displayed.
• Deriving activity from queue/status. It does report per-session work units, but keyed by internal session ids rather than the session names used everywhere else, and it reflects processing rather than message arrival. Wrong tool for the question.
• Relabelling the UI, which is what I ended up shipping: the card now says "Newest Sessions" and labels the timestamp as creation time. That removes the false impression, but it does not give users the view they actually wanted.

Additional context

Observed against Honcho 3.0.11, workspace with 1042 sessions and ~36k conclusions.

Happy to open a PR if you can point me at where the session read model is assembled, and whether you would prefer a stored column updated on message insert or a computed value at read time.