feat(protocol): define missing rollout turn items

[owenlin0]

Description

This PR adds canonical core TurnItem shapes for command execution, dynamic tool calls, collab agent tool calls, and sub-agent activity, to be stored in the rollout file soon.

It also teaches app-server protocol / ThreadHistoryBuilder how to render those items, and adds the small legacy fanout helpers needed for existing event-based consumers. No core producer or rollout persistence behavior changes here, that will be done in a followup.

Making ThreadHistoryBuilder stateless

This is the first PR in a stack to make ThreadHistoryBuilder stateless enough that we can materialize app-server ThreadItems from only a given slice of RolloutItem history, without ever needing to replay the whole thread from the beginning.

The persisted legacy RolloutItem::EventMsg records are mostly shaped like live UI events, not like materialized ThreadItems. They work if we replay the full rollout in order, but they often do not contain enough stable identity or complete item state to project an arbitrary suffix on its own.

A few examples:

• UserMessageEvent and AgentMessageEvent have content, but historically do not carry the persisted app-server item ID that should become the SQLite primary key.
• AgentReasoningEvent and AgentReasoningRawContentEvent are fragments. ThreadHistoryBuilder currently merges them into the last reasoning item, which means a slice starting in the middle of reasoning cannot know whether to append to an earlier item or create a new one.
• WebSearchEndEvent, McpToolCallEndEvent, collab end events, and similar legacy events can often render a final-looking item, but they usually rely on prior replay state to know which turn owns the item.
• Begin/end legacy events are partial views of one logical item. The builder correlates them by call_id and mutates prior state to synthesize the final ThreadItem.

That is the problem this direction fixes. A persisted canonical lifecycle record looks much closer to the read model we actually want later:

ItemCompletedEvent {
    turn_id,
    item: TurnItem { id, ...full snapshot... },
    completed_at_ms,
}

Once rollout has explicit turn_id, stable item.id, and a canonical completed item snapshot, the future SQLite projector can reduce only the new rollout suffix and upsert the affected thread_items rows. It no longer needs to synthesize item-N, infer item ownership from the active turn, or replay earlier events just to reconstruct the current item snapshot.

What changed

• Added core TurnItem variants and item structs for command execution, dynamic tool calls, collab agent tool calls, and sub-agent activity.
• Added conversions from those canonical items back into the legacy event shapes where current consumers still need them.
• Added app-server v2 ThreadItem conversion for the new core item variants.
• Taught ThreadHistoryBuilder and rollout persistence metrics to recognize the new item variants.

Follow-up

The next PR #30283 switches the live core producers for these item families onto canonical ItemStarted / ItemCompleted events.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 2d0b5567ff

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[wiltzius-openai]

Need to consider how to modify the rollout persistence policy for these new types