Distinguish between agent conversation model update types

[lucieleblanc]

Description

The "Runs" agent management view rebuilds its entire card list whenever any conversation's status changes. Most of those events are visually no-ops (re-emitted statuses or status changes that don't cross the active filter), but subscribers can't tell because the event carries no detail.

This PR is the first of two and only changes the shape of the conversation status update event. Subscribers continue to behave exactly as before. The follow-up PR uses the new payload to skip rebuilds when possible.

Concretely:

• BlocklistAIHistoryEvent::UpdatedConversationStatus now carries the previous and new ConversationStatus. Restoration events report prev_status: None since restoration doesn't change the underlying status.
• AgentConversationsModelEvent::ConversationUpdated now carries a conversation_id and a typed ConversationUpdateKind of either Restored or StatusSet { prev_filter, new_filter }. Filter buckets are precomputed at emission time so subscribers don't have to recompute membership.
• A small helper conversation_status_filter maps ConversationStatus to its StatusFilter bucket.
• All existing subscribers were updated to the new event shape with { .. } patterns and ignore the new fields. The variant is annotated with #[allow(dead_code)] until the follow-up PR lands.

Testing

Added/updated four unit tests on the model: Restored emission, changing filter buckets, same-bucket re-emission, and the ConversationStatus --> StatusFilter mapping.

Server API dependencies

No server dependencies.

[oz-for-oss]

@lucieleblanc

I'm starting a first review of this pull request.

You can view the conversation on Warp.

I completed the review and no human review was requested for this pull request.

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

[oz-for-oss]

Overview

This PR enriches conversation status update events with previous/new status and precomputed status-filter bucket details, while preserving current subscriber behavior. The model and subscriber updates are consistent with the existing status mapping, and the added unit coverage exercises restored events, bucket transitions, same-bucket re-emissions, and status-to-filter mapping.

Concerns

• No blocking correctness, security, error-handling, or performance concerns found in the changed diff.

Verdict

Found: 0 critical, 0 important, 0 suggestions

Approve

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

[liliwilson]

Nice fix!

[liliwilson]

Thoughts on storing AgentRunDisplayStatus here instead of StatusFilter? We can use from_conversation_status to get it, and means we don't need a new conversation_status_filter method since AgentRunDisplayStatus already has a status_filter

[liliwilson]

nit: what do you think about something like

enum ConversationStatusUpdate {
    Restored,
    Changed { prev_status: ConversationStatus },
}

UpdatedConversationStatus {
  // ...
  update: ConversationStatusUpdate,
  new_status: ConversationStatus
}

since prev_status and is_restored are pretty coupled