analytics: ingest responses api call events

[rhan-oai]

Why

After defining the Responses API call schema, the analytics client and reducer need to know how to turn a core-facing input into the final backend event. This PR wires that schema into the existing analytics pipeline while keeping Responses item processing inside the analytics crate.

What changed

This adds AnalyticsEventsClient::track_responses_api_call, which accepts a CodexResponsesApiCallInput, carries the precomputed item metadata and item counts into a CustomAnalyticsFact::ResponsesApiCall, derives token fields, and records the custom fact.

The reducer now ingests CustomAnalyticsFact::ResponsesApiCall and emits a codex_responses_api_call_event only when the required context is available: connection metadata, thread lifecycle metadata, turn metadata, and resolved turn config. The emitted event is enriched with thread source, initialization mode, parent/subagent fields, client/runtime metadata, model/provider, and reasoning effort in the same style as the existing turn analytics events.

This also adds serialization and reducer tests for the new event. The tests cover the backend payload shape and verify that a custom Responses API call fact is reduced into the expected event once the normal analytics prerequisites have been observed.

Verification

Verified with cargo test -p codex-analytics, including the new serialization and reducer coverage for codex_responses_api_call_event.

---

Stack created with Sapling. Best reviewed with ReviewStack.

• core: emit responses api call analytics #18030
• -> analytics: ingest responses api call events #18029
• analytics: add responses api call schema #18028