feat(sidebar): show user-turn count alongside total messages

Problem

The Detailed session-sidebar view currently shows a single total such as 18 msgs. That total does not quickly distinguish a genuinely interactive conversation from:

• a cron run with one automated prompt and many assistant/tool messages;
• a one-question/one-answer session;
• a tool-heavy agent run; or
• a conversation with substantial user back-and-forth.

This makes session-history cleanup harder than it needs to be. The useful triage signal is the number of persisted user-role turns alongside the total stored-message count.

Existing support

Most of the underlying support already exists:

• Session-list payloads expose user_message_count.
• PR #1587 already uses user-turn counts to filter low-value untitled CLI sessions, establishing this as a useful session-triage signal.
• Issue #673 / PR #764 introduced Compact and Detailed sidebar density modes; Detailed mode already has a metadata row for message count, model, and source/profile.
• Cron/source visibility remains a separate concern via #2841 and related origin-filter work.

I could not find an existing issue or PR proposing this exact user-versus-total presentation.

Proposed UX

In Detailed density mode, change the existing count metadata from:

18 msgs · gpt-5.6-sol · WebUI

to something explicit such as:

3 user turns · 18 total · gpt-5.6-sol · WebUI

Compact mode should remain unchanged to preserve sidebar density.

A tooltip could clarify the semantics:

3 user-role messages; 18 stored messages including assistant and tool activity. Automated sources may also create user-role messages.

Why this is useful

An anonymized aggregate check against a real mixed Hermes session corpus showed:

• 91.6% of non-empty cron sessions had exactly one user-role message.
• 65.6% of non-empty WebUI sessions had two or more user-role messages.
• Among sessions with two or more user-role messages, 90.8% came from interactive surfaces (WebUI, Telegram, Discord, or TUI) rather than cron/subagent sources.

This is not a perfect human-versus-automation classifier, but it is a strong, immediately scannable cleanup signal when shown together with source metadata.

Examples:

• 1 user turn · 2 total — likely a simple question and answer
• 1 user turn · 84 total · Cron — likely an automated/tool-heavy run
• 7 user turns · 63 total · WebUI — clearly an interactive conversation

Semantic and implementation requirements

1. Do not label this as definitively human input. Cron instructions and other automated prompts may also be persisted with role='user'; source/origin must remain visible.
2. Define “total” clearly. The existing raw count can include assistant, tool, and internal records, so avoid implying it represents only visible chat bubbles.
3. Make the value lineage-aware. A compressed conversation displayed as one logical sidebar row should report counts for the visible conversation lineage, not only the latest storage segment. Otherwise a long conversation may appear to have only one recent user turn after compression.
4. Reuse indexed/payload metadata. Rendering the count should not trigger a full transcript scan per sidebar row.
5. Provide a compatibility fallback. If user_message_count is unavailable or unknown, retain the current N msgs display rather than showing a misleading zero.
6. Use localized strings/pluralization. Avoid embedding an unexplained abbreviation such as U as the only presentation.

Suggested acceptance criteria

• Detailed sidebar rows show user-role turns and total stored messages.
• Compact sidebar rows remain unchanged.
• Source/profile metadata remains visible in Detailed mode.
• Missing/unknown user counts fall back safely to the current total-only display.
• Compressed/continued lineages report counts consistently for the logical visible conversation.
• Singular/plural and tooltip text are localized.
• Tests cover WebUI, cron, imported agent/CLI, missing-count compatibility, and compressed-lineage sessions.

A future filter such as “0–1 user turns” could build on this, but it is intentionally out of scope for this issue.