list_sessions MCP tool should expose startedAt alongside lastActivityAt

Summary

The mcp__ccd_session_mgmt__list_sessions tool returns lastActivityAt for each session but does not expose startedAt. For long-running multi-day CLI sessions, this makes the session's temporal span invisible — it appears only by its last-activity date.

Current output

{
  "sessionId": "...",
  "title": "...",
  "cwd": "...",
  "branch": "...",
  "isArchived": false,
  "isRunning": false,
  "lastActivityAt": "2026-05-07T13:37:27Z"
}

Proposed output

{
  "sessionId": "...",
  "title": "...",
  "cwd": "...",
  "branch": "...",
  "isArchived": false,
  "isRunning": false,
  "startedAt": "2026-04-30T08:00:56Z",
  "lastActivityAt": "2026-05-07T13:37:27Z",
  "eventCount": 3600
}

Why this matters

1. Multi-day sessions are common. A 7-day continuous CLI session (3,600 events) showed up only by its last-activity date. Without startedAt, its full temporal span was invisible, causing confusion about which session covered which time window.

1. Forensics and audit. "Which session covered the time window when X happened?" is unanswerable from listing-tool output alone for multi-day sessions.

1. Cross-session reasoning. When an agent discusses "the prior session," both operator and agent need shared session-temporal-bounds. Currently asymmetric.

The data exists

The session JSONL's first event already contains the start timestamp — the tool just doesn't surface it. startedAt = first event's timestamp field. eventCount = line count.

Backwards compatibility

Both fields are purely additive — no breaking change.