feat(workspace): add last_user_message_at field for better activity tracking

[jonathanlab]

Context: previously we'd based the chronological list on a bunch of stuff:

• last agent response
• last permission request
• last user message

this felt quite inconsistent, and there were some bugs with old threads moving up in the chronological sort if you opened them without doing anything.
let's simplify!

Added a new last_user_message_at column to the workspaces table to track when users last sent messages, enabling proper sorting in the sidebar. Existing data is migrated from the last_activity_at column.

---

Created with PostHog Code

[greptile-apps]

Comments Outside Diff (1)

1. apps/code/src/renderer/features/sidebar/hooks/useSidebarData.ts, line 223-224 (link)

   isUnread vs. sort-key mismatch: sorting in "updated" mode now uses lastUserMessageAt, but the unread badge still fires on lastActivityAt > lastViewedAt. This means tasks where AI has responded (but the user hasn't sent a new message) will show an unread badge while staying below tasks the user recently messaged — the unread indicator and the sort position can diverge. If the PR description's "proper unread badge handling" intends to tie the badge to user activity rather than AI responses, isUnread should also compare lastUserMessageAt against lastViewedAt. If AI-response-driven badges are intentional, a short comment explaining the deliberate split would prevent future confusion.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: apps/code/src/renderer/features/sidebar/hooks/useSidebarData.ts
   Line: 223-224
   
   Comment:
   `isUnread` vs. sort-key mismatch: sorting in "updated" mode now uses `lastUserMessageAt`, but the unread badge still fires on `lastActivityAt > lastViewedAt`. This means tasks where AI has responded (but the user hasn't sent a new message) will show an unread badge while staying below tasks the user recently messaged — the unread indicator and the sort position can diverge. If the PR description's "proper unread badge handling" intends to tie the badge to user activity rather than AI responses, `isUnread` should also compare `lastUserMessageAt` against `lastViewedAt`. If AI-response-driven badges are intentional, a short comment explaining the deliberate split would prevent future confusion.
   
   How can I resolve this? If you propose a fix, please make it concise.

Prompt To Fix All With AI

Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 2
apps/code/src/renderer/features/sidebar/hooks/useTaskViewed.ts:117-123
The `markActivity` return value is now dead code — no caller destructures it from `useTaskViewed()`. All usages in React components (`useSessionCallbacks`, `SidebarMenu`, `CommandCenterView`, `useTaskDeepLink`) destructure only `markAsViewed`, `markUserSend`, or `timestamps`. The only live path for `markActivity` is `taskViewedApi.markActivity` (the non-React imperative API), which is unrelated to this hook return. Removing it keeps the API surface aligned with simplicity rule 4.

```suggestion
  return {
    timestamps,
    isLoading,
    markAsViewed: markViewedMutation.mutate,
    markUserSend: markUserSendMutation.mutate,
  };
```

### Issue 2 of 2
apps/code/src/renderer/features/sidebar/hooks/useSidebarData.ts:223-224
`isUnread` vs. sort-key mismatch: sorting in "updated" mode now uses `lastUserMessageAt`, but the unread badge still fires on `lastActivityAt > lastViewedAt`. This means tasks where AI has responded (but the user hasn't sent a new message) will show an unread badge while staying below tasks the user recently messaged — the unread indicator and the sort position can diverge. If the PR description's "proper unread badge handling" intends to tie the badge to user activity rather than AI responses, `isUnread` should also compare `lastUserMessageAt` against `lastViewedAt`. If AI-response-driven badges are intentional, a short comment explaining the deliberate split would prevent future confusion.

_{Reviews (1): Last reviewed commit: "feat(workspace): add last_user_message_a..." | Re-trigger Greptile}

[greptile-apps]

The markActivity return value is now dead code — no caller destructures it from useTaskViewed(). All usages in React components (useSessionCallbacks, SidebarMenu, CommandCenterView, useTaskDeepLink) destructure only markAsViewed, markUserSend, or timestamps. The only live path for markActivity is taskViewedApi.markActivity (the non-React imperative API), which is unrelated to this hook return. Removing it keeps the API surface aligned with simplicity rule 4.

Suggested change

	return {
	timestamps,
	isLoading,
	markAsViewed,
	markActivity,
	getLastViewedAt,
	getLastActivityAt,
	markAsViewed: markViewedMutation.mutate,
	markActivity: markActivityMutation.mutate,
	markUserSend: markUserSendMutation.mutate,
	};
	return {
	timestamps,
	isLoading,
	markAsViewed: markViewedMutation.mutate,
	markUserSend: markUserSendMutation.mutate,
	};

Prompt To Fix With AI

This is a comment left during a code review.
Path: apps/code/src/renderer/features/sidebar/hooks/useTaskViewed.ts
Line: 117-123

Comment:
The `markActivity` return value is now dead code — no caller destructures it from `useTaskViewed()`. All usages in React components (`useSessionCallbacks`, `SidebarMenu`, `CommandCenterView`, `useTaskDeepLink`) destructure only `markAsViewed`, `markUserSend`, or `timestamps`. The only live path for `markActivity` is `taskViewedApi.markActivity` (the non-React imperative API), which is unrelated to this hook return. Removing it keeps the API surface aligned with simplicity rule 4.

```suggestion
  return {
    timestamps,
    isLoading,
    markAsViewed: markViewedMutation.mutate,
    markUserSend: markUserSendMutation.mutate,
  };
```

How can I resolve this? If you propose a fix, please make it concise.