[codex-analytics] add item lifecycle timing

[rhan-oai]

Why

Tool families already disagree on what their existing duration fields mean, so lifecycle latency should live on the shared item envelope instead of being inferred from per-tool execution fields. Carrying that envelope through app-server notifications gives downstream consumers one reusable timing signal without pretending every tool has the same execution semantics.

What changed

• Adds started_at_ms to core ItemStartedEvent values and completed_at_ms to core ItemCompletedEvent values.
• Populates those timestamps in the shared session lifecycle emitters, so protocol-native items get timing without each producer tracking its own clock state.
• Exposes startedAtMs on app-server item/started notifications and completedAtMs on item/completed notifications.
• Maps the lifecycle timestamps through the app-server boundary while leaving legacy-converted notifications nullable when no lifecycle timestamp exists.
• Regenerates the app-server JSON schema and TypeScript fixtures for the notification-envelope change and updates downstream fixtures that construct those notifications directly.
• Extends the existing web-search and image-generation integration flows to assert the new lifecycle timestamps on the native item events.

Verification

• cargo check -p codex-protocol -p codex-core -p codex-app-server-protocol -p codex-app-server -p codex-tui -p codex-exec -p codex-app-server-client
• cargo test -p codex-core --test all web_search_item_is_emitted
• cargo test -p codex-core --test all image_generation_call_event_is_emitted
• cargo test -p codex-app-server-protocol

---

Stack created with Sapling. Best reviewed with ReviewStack.

• [codex-analytics] emit terminal tool review events #18748
• [codex-analytics] add tool review event schema #18747
• [codex-analytics] emit tool item events from item lifecycle #17090
• [codex-analytics] add tool item event schemas #17089
• -> [codex-analytics] add item lifecycle timing #20514

[owenlin0]

let's see if we can make these timestamps non-optional. first at the core layer, then at app-server (if possible). want to give it a shot? this would be much nicer instead of keeping around optional forever 🙏

[owenlin0]

let's make this non-optional. it's safe because we never persisted ItemStartedEvent in rollouts :)

[owenlin0]

Let's make this non-optional too. Can we do something like this?

fn unknown_completed_at_ms() -> i64 {
    0
}

pub struct ItemCompletedEvent {
    // other fields
    // ...
    #[serde(default = "unknown_completed_at_ms")]
    pub completed_at_ms: i64,
}

I think we need this since we read EventMsg::ItemCompleted(TurnItem::Plan(_)) from rollout files, so we want to keep that deserializing properly with a serde(default).

[owenlin0]

and i think it's totally fine to return 0 since app-server only exposes item/completed notification while streaming a thread live. APIs that return thread history doesn't use this.

[owenlin0]

let's make sure to add the #[ts(type = "number")] annotation for this field

[owenlin0]

here too

[owenlin0]

nit: can we call out ItemCompleted for PlanItem in particular? that's the only one that ever got persisted

[owenlin0]

small comments but overall lgtm!